From: Hubertus Franke <frankeh@watson.ibm.com>
To: Peter Williams <peterw@aurema.com>
Cc: Shailabh Nagar <nagar@watson.ibm.com>,
kanderso@redhat.com, Rik van Riel <riel@redhat.com>,
Chandra Seetharaman <sekharan@us.ibm.com>,
limin@sgi.com, jlan@sgi.com, linux-kernel@vger.kernel.org,
jh@sgi.com, Paul Jackson <pj@sgi.com>,
gh@us.ibm.com, Erik Jacobson <erikj@subway.americas.sgi.com>,
ralf@suse.de, Vivek Kashyap <kashyapv@us.ibm.com>,
lse-tech@lists.sourceforge.net, mason@suse.com
Subject: Re: Minutes from 5/19 CKRM/PAGG discussion
Date: Tue, 25 May 2004 11:19:59 -0400 [thread overview]
Message-ID: <40B3641F.508@watson.ibm.com> (raw)
In-Reply-To: <40B2CB0E.8030606@aurema.com>
Peter Williams wrote:
> Peter Williams wrote:
>
>> Hubertus Franke wrote:
>>
>>>
>>> One important input the PAGG team could give is some real
>>> examples where actually multiple associations to different groups
>>> is required and help us appreciate that position and let us
>>> see how this would/could be done in CKRM.
>>
>>
>>
>> One example would be the implementation of CPU sets (or pools) a la
>> Solaris where there are named CPU pools to which processors and
>> processes are assigned. Processors can be moved between CPU pools
>> and when this happens it is necessary to visit all the processes that
>> are assigned to the pools involved (one losing and one gaining the
>> processor) and change their CPU affinity masks to reflect the new
>> assignment of processors. PAGG would be ideal for implementing this.
>>
>> At the same time, a resource management client could be controlling
>> resources allocated to processes based on some other criteria such as
>> the real user or the application being run without regard to which
>> CPU pool they are running in.
>
>
> Additionally, it seems to me that even within the field of resource
> management it is not necessarily the case that the same grouping is
> required for different resource types e.g. the grouping for control of
> CPU resources might be different to the grouping for control of
> network bandwidth allocation or disk space or disk I/O bandwidth, etc.
>
> Peter
Correct, that is in principle possible. We went through this discussion
on the mailing list .. (Rik, Shailabh help me out here) and decided
that mostly that is
not being required. The extra overhead of putting that we deemed
unnecessary.
Instead, if really desired, one would require a different classtype for
each of those groupings. Note however, our entire infrastructure already
supports that in that RCFS would pick these specialized class types up,
provide the proper hierarchy as an FS subdirectory structure. For us it
was mainly a question how we can get the most out of the initial
prototype without having general users have to go and specify all kinds
of hierarchies, i.e. one per resource.
-- Hubertus
next prev parent reply other threads:[~2004-05-25 15:22 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-05-24 17:09 Minutes from 5/19 CKRM/PAGG discussion Hanna Linder
2004-05-24 17:39 ` Hanna Linder
2004-05-24 18:05 ` Rik van Riel
2004-05-24 19:55 ` Hubertus Franke
2004-05-24 23:43 ` Peter Williams
2004-05-25 15:00 ` Hubertus Franke
2004-05-26 1:31 ` Peter Williams
2004-05-25 1:55 ` Peter Williams
2004-05-25 4:26 ` Peter Williams
2004-05-25 15:19 ` Hubertus Franke [this message]
2004-05-26 1:53 ` Peter Williams
2004-05-25 15:13 ` [Lse-tech] " Hubertus Franke
2004-05-26 1:44 ` Peter Williams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=40B3641F.508@watson.ibm.com \
--to=frankeh@watson.ibm.com \
--cc=erikj@subway.americas.sgi.com \
--cc=gh@us.ibm.com \
--cc=jh@sgi.com \
--cc=jlan@sgi.com \
--cc=kanderso@redhat.com \
--cc=kashyapv@us.ibm.com \
--cc=limin@sgi.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lse-tech@lists.sourceforge.net \
--cc=mason@suse.com \
--cc=nagar@watson.ibm.com \
--cc=peterw@aurema.com \
--cc=pj@sgi.com \
--cc=ralf@suse.de \
--cc=riel@redhat.com \
--cc=sekharan@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox