Messages in this thread | | | Date | Thu, 12 Aug 2004 00:15:22 -0700 | From | Paul Jackson <> | Subject | Re: [Lse-tech] [PATCH] cpusets - big numa cpu and memory placement |
| |
Shailabh wrote: > But when apps are being confined to a set of cpus *only* for purposes of > getting a certain fraction of the total compute power, cpusets are not > orthogonal in intent, not implementation, from a CKRM CPU class > implementing hard limits.
So if someone wanted to constrain a group of tasks to using 50% of all the available CPU ticks on a 32 CPU system, they could either use a CKRM CPU class with a hard limit of 50%, or a cpuset that contained 16 CPUs.
Yes, for that purpose, except for NUMA placement (the cache affinity and memory latency you mention), these two approaches are similar in affect.
So, yes, my absolute insistence that CKRM and cpusets are orthogonal is overstated. Well, I could quibble that orthogonal doesn't imply disjoint. Whatever.
> What's your opinion on the commonalities between the two interfaces > pointed out in my previous mail ?
My apologies for not yet replying to your mail of a couple of days ago. It was valuable to me, and I've taken a bit of time to digest it. Meanwhile, newer stuff keeps overruning my reply. Soon, hopefully.
> Also, if CKRM were to move to the "each controller exports its own > interface" model, how would this affect the discussion ?
I cannot speak for the discussion, only for myself. I am clearly sensitive to the downsides of trying to integrate these interfaces.
Hopefully I can find the time tonight to study your earlier replies more closely, and better understand the potential benefits of such an integration. So far, I don't see them. I will do my best to keep my eyes and mind open. Thanks especially to your posts, I have learned quite a bit about CKRM this week.
I will confess to a strong bias toward a minimum of abstraction at the kernel-user boundary, and towards providing a one-to-one map between the mechanisms and the interfaces a kernel provides. Let the user level assemble the pieces as it will. If combining interfaces (CKRM and cpuset) caused any unwarranted change in or obfuscation of the semantics provided by either, that would be unfortunate, in my view.
> Do you think there's *any* merit to cpusets sharing the rcfs > interface *if* the latter were to make the changes mentioned in earlier > mail ?
Not yet, but I need to go back over your replies, and others, with this question more clearly in focus.
> If not (and others agree), lets end this discussion and move on - both > projects have enough to do ...
At least Martin does not yet agree, if I understand his posts. But, yes, either way, we are close to where it is best to table this discussion, for the moment at least.
Thank-you for your constructive and enlightening comments so far.
-- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <pj@sgi.com> 1.650.933.1373 - 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/
| |