static int's for proc_change_penalty and tlb_flush_penalty

[Andrea Arcangeli]

On Wed, 19 Jan 2000, James Manning wrote:

>I was thinking about making the penalties in goodness() for processor
>change and TLB flushes into static int's and putting them into /proc
>for ppl to be able to "tune" their SMP scheduler (and to find out with
>some user feedback if there are more appropriate defaults for them,
>or whether it should really be settable per-system) but realized that
>even as a pair of static int's, the misses of that cache line may be
>adverse enough to ruin any chance of this being a worth-while change,
>so I wanted to get your opinion on this.

I think it could be a very good idea for the 2.3.x kernel since it will
allow people to trivially tune things at runtime and report the best
values. I am not sure if it worth to have the cacheline penality in 2.4.x
consdiering I don't like by-hand settings, and that the scheduler
algorithm should have the best values as default. Anyway there's to say
that the cacheline penality matters when you have an huge number tasks in
the runqueue and in such a scenario probably you want to rewrite the
scheduler to avoid having to check all tasks in the first place to run in
almost O(1) instead of O(n). Davide Libenzi just did that and his code is
not been included with the argument that "lots of running tasks" is not
common case even for heavily loaded servers.

If the scheduler will run in almost O(1) (like with Davide's code) the
cachelines penality won't be noticeable anymore (just like you can't
measure it with only one process in the runqueue). Nevertheless things
like task_struct cacheline optimizations will continue to make always
perfect sense and they are a good thing and obviously right indeed :-).

I did smilar cacheline optimizations for the buffer_head some time ago. I
discussed the buffer_head changes with SCT and Mark Hemment IIRC. My patch
is never been included into the official kernel IIRC and I think that it's
sleeping into my 2.2.9_andrea? patches.

>Since these are just scheduling policy changes, atomicity WRT the int's
>shouldn't matter (although the /proc change function should keep some
>reasonable bounds)

Yes, that's definitely a completly safe thing to do. The only writer is
the sysctl interface and it's not necessary that all CPUs sees the change
at the same time. And there won't be any cacheline collision across
different CPU and the memory will be shared in all cachelines.

Andrea


-
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/