[lkml]   [2006]   [Jun]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-16 13:05    [W:0.027 / U:13.124 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site