static int's for proc_change_penalty and tlb_flush_penalty

[Chuck Lever]

On Fri, 21 Jan 2000, James Manning wrote:

> Date: Fri, 21 Jan 2000 11:09:47 -0500
> From: James Manning <jmm en raleigh.ibm.com>
> To: Chuck Lever <cel en monkey.org>
> Cc: linux-kernel en vger.rutgers.edu
> Subject: Re: static int's for proc_change_penalty and tlb_flush_penalty
> 
> [ Friday, January 21, 2000 ] Chuck Lever wrote:
> > what might be nice is having the kernel configuration process select the
> > proper constant values based on the CPU hardware type you've selected, and
> > whether SMP is enabled.
> 
> My initial feeling agreed with this, but after Andrea mentioned
> self-tuning and a few cases were brought up, I realize that it's
> dependent upon the process mix of the workload.  Good loop-blocking code
> will be very sensitive but programs just dealing with external input
> (streaming files, network input, etc) shouldn't be nearly as sensitive
> as the D$ misses are going to be there on any processor.  How harmful
> the I$ misses are will depend on the code characteristics/working set.
> Streaming apps which deal with data once and toss it vs. block-processing
> (rc5, setiathome, jpeg-ish kinds of things) programs should be handled
> differently. In much the same manner as your madvise() additions helped
> bring that reality to the kernel for mmap() behavior, the scheduler
> should more sensitive to these differences if possible.

those sound like productive ideas.  my concern was mostly for
practicality, in terms of what might be acceptible to those who are
worried about cache miss latency in production kernels.

> Now since self-tuning can be tricky (if not just unrealistic) selecting
> a good value at compile time could be a good idea, but if, say, SMP P6
> is selected that still doesn't help differentiate between 2-way PPro's
> and 128K celeron's from 8-way 2MB Xeon's, and esp. with the Profusion
> around and the competition of more and larger caches per bus, I'm not
> sure this range is very tight.

certainly, the scheduler variables could be read out of a table during
processor detection, but we still have the problem of cache misses when
accessing the values.

> Just to make sure I'm not missing something... if SMP's not enabled then
> processor change doesn't even make sense, so allowing it to be tunable
> or picking a different value for it won't matter.  Now the TLB flush
> penalty could definitely vary per-CPU, and picking a good default value
> for this based on CPU hardware type at config time does make sense.

that's what i was thinking, but i'm no expert.

	- Chuck Lever
--
corporate:	<chuckl en netscape.com>
personal:	<chucklever en netscape.net> or <cel en monkey.org>

The Linux Scalability project:
	http://www.citi.umich.edu/projects/linux-scalability/


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo en vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/