Messages in this thread | | | Date | Fri, 16 Jun 2006 13:02:09 +0200 | From | Jes Sorensen <> | Subject | Re: FOR REVIEW: New x86-64 vsyscall vgetcpu() |
| |
Andi Kleen wrote: >> In the scientific application space, there are two very common >> groupings of jobs. > > The scientific users just use pinned CPUs and seem to be happy with that. > They also have cheap slav^wgrade students to spend lots of time on > manual tuning. I'm not concerned about them.
Do they? There's a lot of scientific sites out there which are not universities or research organizations. They do not have free slave labour at hand. A lot of users fall into this category, especially the users with larger systems or large clusters (be it ia64, x86_64 or PPC).
> If you already use CPU affinity you should already know where you are and don't > need this call at all.
Except that whats currently available isn't sufficient to do what is needed.
> So this clearly isn't targetted for them. > > Interesting is getting the best performance from general purpose applications > without any special tuning. For them I'm trying to improve things.
Well I am interested in getting the best performance for some of the same applications, without having to modify them. The current affinity support simply isn't sufficient for that. Placement has to be targetted at launch time since thread implementations can change the layout etc.
> Number one applications currently are databases and JVMs. I hope with > Wolfam's malloc work it will be useful for more applications too.
If you want this to work for general purpose applications, then how is this new syscall going to help? If you expect application vendors to code for it, that means few users will benefit.
>> I really don't think this approach is going to solve the problem. As >> Tony also points out, tasks will eventually migrate. > > Currently we don't solve this problem with the standard heuristics. > It can be solved with manual tuning (mempolicy, explicit CPU affinity) > but if you're doing that you're already out side the primary use > case of vgetcpu().
This is another area where the kernel could do better by possibly using the cpumask to determine where it will allocate memory.
> vgetcpu() is only trying to be a incremental improvement of the current > simple default local policy.
As Tony rightfully pointed out, tasks do migrate. By making this guess initially and then expecting the application to run for a long time, you will end up with it having zero or possibly a negative effect.
>> The user needs to > > Scientific users do that, but other users normally not. I doubt that > is going to change.
I just use scientific users since thats where I have the most recent detailed data from. Databases could well benefit from what I mentioned, though the serious ones would want to look into using affinity support explicitly in their code.
Cheers, Jes - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |