* Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> On Tue, Oct 23, 2007 at 07:32:27PM -0700, Paul Menage wrote:
> > Clean up some CFS CGroup code
> >
> > - replace "cont" with "cgrp" in a few places in the CFS cgroup code,
> > - use write_uint rather than write for cpu.shares write function
> >
On Tue, 2007-10-23 at 20:43 -0700, David Miller wrote:
> From: Pavel Emelyanov <[EMAIL PROTECTED]>
> Date: Tue, 23 Oct 2007 20:37:22 +0400
> > The /proc/net udp6, tcp6 and raw6 files print the IPs of
> > the connection ends. Make a NIP6Lxxx macros (L stands for
> > "long") for making the printing c
On Tue, 2007-10-23 at 21:10 -0700, David Miller wrote:
> We'll break things if we change it.
Maybe, but definitely the macro names should
reflect this brokenness.
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo/devel
On Tue, Oct 23, 2007 at 07:20:19PM -0700, Paul Menage wrote:
> OK, if no-one has any complaints about this I'll send it on to akpm.
Looks good to me ..
--
Regards,
vatsa
___
Containers mailing list
[EMAIL PROTECTED]
https://lists.linux-foundation.org/m
On Tue, Oct 23, 2007 at 07:32:27PM -0700, Paul Menage wrote:
> Clean up some CFS CGroup code
>
> - replace "cont" with "cgrp" in a few places in the CFS cgroup code,
> - use write_uint rather than write for cpu.shares write function
>
> Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
Acked-by :
On Tue, Oct 23, 2007 at 07:28:22PM -0700, Paul Menage wrote:
> > Good point. I think we need to subtract out the time it was waiting on
> > runqueue
> > when calculating idle time.
> >
> > |--- . . . . . . -...---|
> > t0 t1t2
From: Joe Perches <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 21:15:36 -0700
> On Tue, 2007-10-23 at 21:10 -0700, David Miller wrote:
> > We'll break things if we change it.
>
> Maybe, but definitely the macro names should
> reflect this brokenness.
That's a good point, we don't want to encourage
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 19:56:04 +0400
> In case the "multiple tables" config option is y, the ip_fib_local_table
> is not a variable, but a macro, that calls fib_get_table(RT_TABLE_LOCAL).
>
> Some code uses this "variable" *3* times in one place, thus im
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 19:28:22 +0400
> Instead of ugly extern not-existing function.
I can take credit for this turd. Hey, it was the accepted way to do
compile time assertions at the time :-)
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Appli
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 19:25:50 +0400
> Inconsistent prototype and real type for functions may have
> worse consequences, than those for variables, so move them
> into a header.
>
> Since they are used privately in net/core, make this file
> reside in the
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Mon, 22 Oct 2007 19:22:43 +0400
> Some are already declared in include/linux/netdevice.h, while
> some others (xfrm ones) need to be declared.
>
> The driver/net/rrunner.c just uses same extern as well, so
> cleanup it also.
>
> Signed-off-by: Pav
From: Joe Perches <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 21:04:01 -0700
> On Tue, 2007-10-23 at 20:43 -0700, David Miller wrote:
> > From: Pavel Emelyanov <[EMAIL PROTECTED]>
> > Date: Tue, 23 Oct 2007 20:37:22 +0400
> > > The /proc/net udp6, tcp6 and raw6 files print the IPs of
> > > the conn
From: Pavel Emelyanov <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 20:37:22 +0400
> The /proc/net udp6, tcp6 and raw6 files print the IPs of
> the connection ends. Make a NIP6Lxxx macros (L stands for
> "long") for making the printing code look nicer.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROT
From: Vlad Yasevich <[EMAIL PROTECTED]>
Date: Tue, 23 Oct 2007 11:57:42 -0400
> Pavel Emelyanov wrote:
> > Both are equal, except for the list to be traversed.
> >
> > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> >
>
> ACK. Good clean-up Pavel.
Yep, nice work, applied.
Thanks!
_
Al Viro <[EMAIL PROTECTED]> writes:
> On Tue, Oct 23, 2007 at 03:20:39PM -0500, Matt Mackall wrote:
>> On Tue, Oct 23, 2007 at 03:03:36AM +0100, Al Viro wrote:
>> >What is the proc_base_stuff[] nonsense about? AFAICS, that
>> > went in with no reason whatsoever in
>> > commit 801199ce805a2412
Clean up some CFS CGroup code
- replace "cont" with "cgrp" in a few places in the CFS cgroup code,
- use write_uint rather than write for cpu.shares write function
Signed-off-by: Paul Menage <[EMAIL PROTECTED]>
---
This is a resend of yesterday's mail with the same subject; the final hunk wa
On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > Suppose you have two cgroups that would each want to use, say, 55% of
> > a CPU - technically they should each be regarded as having 45% idle
> > time, but if they run on a the same CPU the chances are that they will
> > both always hav
OK, if no-one has any complaints about this I'll send it on to akpm.
Paul
On 10/23/07, Paul Menage <[EMAIL PROTECTED]> wrote:
> Move the calls to the cgroup subsystem destroy() methods from
> cgroup_rmdir() to cgroup_diput(). This allows control file reads and
> writes to access their subsystem s
Hello,
I'm new to OpenVZ. I'm interested in learning more about the way OpenVZ
handles its VPS migration, especially the virtualized network stack.
I just downloaded the linux-2.6.18-openvz source code. Can anybody help
me get up to speed by giving some pointers on where in the source
tree to
On Tue, Oct 23, 2007 at 09:41:49AM -0700, Paul Menage wrote:
> > > Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> > > milliseconds for that cgroup's tasks
> >
> > It would be nice to split this into user and sys time at some point.
>
> Sounds reasonable - but does CFS track th
Pavel Emelyanov wrote:
> Both are equal, except for the list to be traversed.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
>
ACK. Good clean-up Pavel.
Thanks
-vlad
___
Devel mailing list
Devel@openvz.org
https://openvz.org/mailman/listinfo
On 10/23/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> > Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> > milliseconds for that cgroup's tasks
>
> It would be nice to split this into user and sys time at some point.
Sounds reasonable - but does CFS track this?
> We have
The /proc/net udp6, tcp6 and raw6 files print the IPs of
the connection ends. Make a NIP6Lxxx macros (L stands for
"long") for making the printing code look nicer.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index 94bc996..5
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> Report CPU usage in CFS Cgroup directories
>
> Adds a cpu.usage file to the CFS cgroup that reports CPU usage in
> milliseconds for that cgroup's tasks
It would be nice to split this into user and sys time at some point.
We have also
On Mon, Oct 22, 2007 at 05:49:39PM -0700, Paul Menage wrote:
> + for_each_possible_cpu(i) {
> + unsigned long flags;
> + spin_lock_irqsave(&tg->cfs_rq[i]->rq->lock, flags);
A simpler form of this would be just:
spin_lock_irqsave(&cpu_rq(i)->lock, flags)
On Mon, Oct 22, 2007 at 11:06:54PM -0700, Paul Menage wrote:
> > > + for_each_possible_cpu(i) {
> > > + unsigned long flags;
> > > + spin_lock_irqsave(&tg->cfs_rq[i]->rq->lock, flags);
> >
> > Is the lock absolutely required here?
>
> I'm not sure, I was hoping you or I
Both are equal, except for the list to be traversed.
Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
---
diff --git a/net/sctp/ulpqueue.c b/net/sctp/ulpqueue.c
index b937095..4be92d0 100644
--- a/net/sctp/ulpqueue.c
+++ b/net/sctp/ulpqueue.c
@@ -908,8 +908,8 @@ void sctp_ulpq_skip(struct sctp
Quoting Crispin Cowan ([EMAIL PROTECTED]):
> Peter, I may be mistaken, but I think you are talking about an entirely
> different issue than the LSM static interface issue, so I've changed the
> subject.
>
> Peter Dolding wrote:
> > You are all focusing on vendors. I am thinking server farm or peo
Alexey Dobriyan wrote:
Code is using knowledge that nf_sockopt_ops::list list_head is first
field in structure by using casts. Switch to list_for_each_entry()
itetators while I am at it.
Applied with a minor warning fix in the compat path, thanks Alexey.
__
On Wed, Oct 17, 2007 at 09:23:02PM -0700, David Miller wrote:
[...]
> > The same problem exists for detaching filter (SO_DETACH_FILTER).
> >
> > The proposed fix consists of 3 preparation patches and the fix itself.
> >
> > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
>
> Looks good, appli
Move the calls to the cgroup subsystem destroy() methods from
cgroup_rmdir() to cgroup_diput(). This allows control file reads and
writes to access their subsystem state without having to be concerned
with locking against cgroup destruction - the control file dentry will
keep the cgroup and its sub
On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Well, without notify_on_release you can never be sure if a new task
> got added to the control group or if someone acquired a reference
> to it. I can't think of a safe way of removing control groups/cpusets
> without using notify_on_release.
Paul Menage wrote:
> On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>> Well, most people who care about deletion will use the notify_on_release
>> callback and retry.
>
> I'm not convinced this is true. Certainly the userspace approaches
> we're developing at Google don't (currently) use not
On 10/23/07, Balbir Singh <[EMAIL PROTECTED]> wrote:
>
> Well, most people who care about deletion will use the notify_on_release
> callback and retry.
I'm not convinced this is true. Certainly the userspace approaches
we're developing at Google don't (currently) use notify_on_release.
Paul
_
Paul Menage wrote:
> On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>> Using cgroup_mutex is certainly possible for now, although more
>> heavy-weight than I'd like long term. Using css_get isn't the right
>> approach, I think - we shouldn't be able to cause an rmdir to fail due
>> to a concur
On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
> On 10/22/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
> >
> > Minor nit: From pov of making this patch series git bisect safe, shouldn't
> > we
> > be registering a write_uint() handler in this patch as well?
> >
>
> Yes, we should. Sigh.
On 10/22/07, Paul Menage <[EMAIL PROTECTED]> wrote:
>
> Using cgroup_mutex is certainly possible for now, although more
> heavy-weight than I'd like long term. Using css_get isn't the right
> approach, I think - we shouldn't be able to cause an rmdir to fail due
> to a concurrent read.
>
OK, the o
37 matches
Mail list logo
