Messages in this thread | | | Date | Thu, 3 Nov 2005 23:45:30 -0800 | From | Paul Jackson <> | Subject | Re: [Lhms-devel] [PATCH 0/7] Fragmentation Avoidance V19 |
| |
Andrew wrote: > > So I will leave that challenge on the table for someone else. > > And I won't merge your patch ;)
Be that way ;).
> Seriously, it does appear that doing it per-task is adequate for your > needs, and it is certainly more general.
My motivations for the per-cpuset, digitally filtered rate, as opposed to the per-task raw counter mostly have to do with minimizing total cost (user + kernel) of collecting this information. I have this phobia, perhaps not well founded, that moving critical scheduling/allocation decisions like this into user space will fail in some cases because the cost of gathering the critical information will be too intrusive on system performance and scalability.
A per-task stat requires walking the tasklist, to build a list of the tasks to query.
A raw counter requires repeated polling to determine the recent rate of activity.
The filtered per-cpuset rate avoids any need to repeatedly access global resources such as the tasklist, and minimizes the total cpu cycles required to get the interesting stat.
> But I have to care for all users.
Well you should, and well you do.
If you have good reason, or just good instincts, to think that there are uses for per-task raw counters, then your choice is clear.
As indeed it was clear.
I don't recall hearing of any desire for per-task memory pressure data, until tonight.
I will miss this patch. It had provided exactly what I thought was needed, with an extremely small impact on system (kern+user) performance.
Oh well.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.925.600.0401 - 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/
| |