Message-Id: <200710310906.l9V96196032714@owlet.beaverton.ibm.com>
To: "Ken Chen" <kenchen@google.com>
cc: "Mathieu Desnoyers" <mathieu.desnoyers@polymtl.ca>,
       "Peter Zijlstra" <peterz@infradead.org>, "Ingo Molnar" <mingo@elte.hu>,
       "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>
Subject: Re: [patch] sched: schedstat needs a diet 
In-reply-to: Your message of "Thu, 18 Oct 2007 15:57:35 PDT."
             <b040c32a0710181557x4741b9ddxeb01edc788defb6@mail.gmail.com> 
Date: Wed, 31 Oct 2007 02:06:01 -0700
From: Rick Lindsley <ricklind@us.ibm.com>
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1324
Lines: 27

    On 10/18/07, Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
    > Good question indeed. How large is this memory footprint exactly ? If it
    > is as small as you say, I suspect that the real issue could be that
    > these variable are accessed by the scheduler critical paths and
    > therefore trash the caches.
    
    Maybe my wording was ambiguous, I meant to reduce cache line pollution
    when accessing these schedstat fields.

As the original author, it was always my intention that schedstats be low
enough impact that it could be turned on all the time, if need be.  That's
why, for the most part, it does increments and decrements of counters and
leaves the actual math to apps that might gather the data.  Initial
measurements showed that it was having no measurable impact on performance.

Of course, that was years ago too.  Systems (and hardware) have changed
considerably in that time.  Are we talking theoretical cache pollution
or measured?  And if measured, what effect is it having?

(sorry for the late followup; was on vacation ...)

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