Messages in this thread | | | Date | Thu, 20 Jan 2000 18:30:14 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: static int's for proc_change_penalty and tlb_flush_penalty |
| |
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@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |