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
-
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Christoph Lameter | [00/41] Large Blocksize Support V7 (adds memmap support) |
| Chuck Ebbert | Re: Linux 2.6.21 |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Hugh Dickins | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
| David Miller | [GIT]: Networking |
