Herbert wrote:
> looks good to me, except for the potential issue with
> the double indirection introducing too much overhear
It's not the indirection count that I worry about.
It's the scalability of the locking. We must avoid as
much as possible adding any global locks on key code paths.
This
Srivatsa Vaddagiri <[EMAIL PROTECTED]> writes:
> On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
>> >Yes me too. But maybe to keep in simple in initial versions, we should
>> >avoid that optimisation and at the same time get statistics on duplicates?.
>>
>> That's an implementation
On Fri, Mar 16, 2007 at 03:19:16PM +0100, Herbert Poetzl wrote:
> > Do you see any drawbacks of doing like this? What will break if we do
> > this?
>
> looks good to me, except for the potential issue with
> the double indirection introducing too much overhear
Sure. I plan to get some numbers
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
> On 3/15/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
> > > If there really was a grouping that was always guaranteed to match
> > > the way you wanted to group tasks
On Thu, Mar 15, 2007 at 10:34:35PM +0530, Srivatsa Vaddagiri wrote:
> On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
> > If there really was a grouping that was always guaranteed to match the
> > way you wanted to group tasks for e.g. resource control, then yes, it
> > would be great
On Thu, Mar 15, 2007 at 10:34:35PM +0530, Srivatsa Vaddagiri wrote:
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
If there really was a grouping that was always guaranteed to match the
way you wanted to group tasks for e.g. resource control, then yes, it
would be great to use
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
On 3/15/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
If there really was a grouping that was always guaranteed to match
the way you wanted to group tasks for e.g.
On Fri, Mar 16, 2007 at 03:19:16PM +0100, Herbert Poetzl wrote:
Do you see any drawbacks of doing like this? What will break if we do
this?
looks good to me, except for the potential issue with
the double indirection introducing too much overhear
Sure. I plan to get some numbers with and
Srivatsa Vaddagiri [EMAIL PROTECTED] writes:
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
Yes me too. But maybe to keep in simple in initial versions, we should
avoid that optimisation and at the same time get statistics on duplicates?.
That's an implementation detail - we
Herbert wrote:
looks good to me, except for the potential issue with
the double indirection introducing too much overhear
It's not the indirection count that I worry about.
It's the scalability of the locking. We must avoid as
much as possible adding any global locks on key code paths.
This
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
> There are some things that benefit from having an abstract
> container-like object available to store state, e.g. "is this
> container deleted?", "should userspace get a callback when this
> container is empty?".
IMO we can still get
On 3/15/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
> If there really was a grouping that was always guaranteed to match the
> way you wanted to group tasks for e.g. resource control, then yes, it
> would be great to use it. But
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
> If there really was a grouping that was always guaranteed to match the
> way you wanted to group tasks for e.g. resource control, then yes, it
> would be great to use it. But I don't see an obvious candidate. The
> pid namespace is not
On 3/12/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
- (subjective!) If there is a existing grouping mechanism already (say
tsk->nsproxy[->pid_ns]) over which res control needs to be applied,
then the new grouping mechanism can be considered redundant (it can
On 3/12/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
- (subjective!) If there is a existing grouping mechanism already (say
tsk-nsproxy[-pid_ns]) over which res control needs to be applied,
then the new grouping mechanism can be considered redundant (it can
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
If there really was a grouping that was always guaranteed to match the
way you wanted to group tasks for e.g. resource control, then yes, it
would be great to use it. But I don't see an obvious candidate. The
pid namespace is not it,
On 3/15/07, Srivatsa Vaddagiri [EMAIL PROTECTED] wrote:
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
If there really was a grouping that was always guaranteed to match the
way you wanted to group tasks for e.g. resource control, then yes, it
would be great to use it. But I
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
There are some things that benefit from having an abstract
container-like object available to store state, e.g. is this
container deleted?, should userspace get a callback when this
container is empty?.
IMO we can still get these
On Tue, Mar 13, 2007 at 11:28:20PM +0530, Srivatsa Vaddagiri wrote:
> On Tue, Mar 13, 2007 at 05:24:59PM +0100, Herbert Poetzl wrote:
> > what about identifying different resource categories and
> > handling them according to the typical usage pattern?
> >
> > like the following:
> >
> > - cpu
On Tue, Mar 13, 2007 at 05:24:59PM +0100, Herbert Poetzl wrote:
> what about identifying different resource categories and
> handling them according to the typical usage pattern?
>
> like the following:
>
> - cpu and scheduler related accounting/limits
> - memory related accounting/limits
> -
On Mon, Mar 12, 2007 at 06:12:26PM +0530, Srivatsa Vaddagiri wrote:
> I happened to read the entire thread (@ http://lkml.org/lkml/2007/3/1/159)
> all over again and felt it may be usefull to summarize the discussions so far.
>
> If I have missed any imp. points or falsely represented someone's
On Mon, Mar 12, 2007 at 06:12:26PM +0530, Srivatsa Vaddagiri wrote:
I happened to read the entire thread (@ http://lkml.org/lkml/2007/3/1/159)
all over again and felt it may be usefull to summarize the discussions so far.
If I have missed any imp. points or falsely represented someone's view
On Tue, Mar 13, 2007 at 05:24:59PM +0100, Herbert Poetzl wrote:
what about identifying different resource categories and
handling them according to the typical usage pattern?
like the following:
- cpu and scheduler related accounting/limits
- memory related accounting/limits
- network
On Tue, Mar 13, 2007 at 11:28:20PM +0530, Srivatsa Vaddagiri wrote:
On Tue, Mar 13, 2007 at 05:24:59PM +0100, Herbert Poetzl wrote:
what about identifying different resource categories and
handling them according to the typical usage pattern?
like the following:
- cpu and scheduler
24 matches
Mail list logo
