sched_autogroup interactivity patch for the desktop

[Ilyes Gouta]

Hi,

http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kerne...
patch: http://marc.info/?l=linux-kernel&m=128978361700898&w=2

Can we have this patch back ported into the current kernel for Fedora 14 and
possibly posted as an update? :)

Would be wonderful!

-Ilyes

[Matthew Garrett]

On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote:
>     Hi,
>    
> http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kerne...
>     patch: http://marc.info/?l=linux-kernel&m=128978361700898&w=2
>     Can we have this patch back ported into the current kernel for Fedora 14
>     and possibly posted as an update? :) 
At the point where it's been demonstrated to be stable and not trigger 
any significant performance regressions we'll consider it, but we don't 
make a habit of backporting code that hasn't even been merged upstream 
into our stable release.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Jason L Tibbitts III]

> >>>> "IG" == Ilyes Gouta
> <ilyes.gouta(a)gmail.com&gt; writes: 
IG> Can we have this patch back ported into the current kernel for
IG> Fedora 14 and possibly posted as an update? :)
IG> Would be wonderful!

Would be more wonderful to wait until the upstream development has
actually finished before cramming it into our packages and hoping it
actually works.  If you really want it, Fedora provides all the tools to
build your own custom kernel package.

 - J<

[Ilyes Gouta]

Hi,

According to phoronix, it would be queued for the 2.6.38 release.

>  actually works.  If you really want it, Fedora provides all the tools
> to
>  build your own custom kernel package. 
It's already on my todo list :)

-Ilyes

On Tue, Nov 16, 2010 at 5:38 PM, Jason L Tibbitts III <tibbs(a)math.uh.edu&gt;wrote:

> >>>>> "IG" == Ilyes Gouta <ilyes.gouta(a)gmail.com&gt;
writes:
>
> IG> Can we have this patch back ported into the current kernel for
> IG> Fedora 14 and possibly posted as an update? :)
> IG> Would be wonderful!
>
> Would be more wonderful to wait until the upstream development has
> actually finished before cramming it into our packages and hoping it
>  actually works.  If you really want it, Fedora provides all the tools
> to
>  build your own custom kernel package. 
>
>  - J<
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Kyle McMartin]

On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote:
>  Can we have this patch back ported into the current kernel for Fedora
> 14 and
>  possibly posted as an update? :)
>  
>  Would be wonderful!
>   
Try this,
http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/
i686 coming whenever mock finishes.

regards, Kyle.

[Ilyes Gouta]

Thanks Kyle for making it available!

-Ilyes

On Tue, Nov 16, 2010 at 5:39 PM, Kyle McMartin <kyle(a)mcmartin.ca&gt; wrote:

>  On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote:
>  > Can we have this patch back ported into the current kernel for Fedora 14
>  and
>  > possibly posted as an update? :)
>  >
>  > Would be wonderful!
>  >
>
>  Try this,
>  http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/
>  i686 coming whenever mock finishes.
>
>  regards, Kyle.
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Ilyes Gouta]

Hi Kyle,

I'm getting these while running
kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/

<http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/>
[  234.580039] BUG: sleeping function called from invalid context at
mm/slub.c:1701
[  234.580048] in_atomic(): 0, irqs_disabled(): 1, pid: 4272, name:
gnome-terminal
[  234.580054] Pid: 4272, comm: gnome-terminal Not tainted
2.6.35.8-59.xsched1.fc14.x86_64 #1
[  234.580058] Call Trace:
[  234.580070]  [<ffffffff8103d03d>] __might_sleep+0xed/0xef
[  234.580079]  [<ffffffff811096b8>] kmem_cache_alloc_notrace+0x37/0xb2
[  234.580085]  [<ffffffff8104af89>] sched_autogroup_create_attach+0x26/0xe1
[  234.580092]  [<ffffffff812a21e0>] __proc_set_tty+0x10d/0x116
[  234.580098]  [<ffffffff812a39be>] tty_ioctl+0x3fc/0x7c5
[  234.580103]  [<ffffffff811244d7>] vfs_ioctl+0x32/0xa6
[  234.580108]  [<ffffffff81124a34>] do_vfs_ioctl+0x46d/0x4a6
[  234.580112]  [<ffffffff81124ac3>] sys_ioctl+0x56/0x79
[  234.580119]  [<ffffffff81009c72>] system_call_fastpath+0x16/0x1b

-Ilyes

On Tue, Nov 16, 2010 at 5:42 PM, Ilyes Gouta <ilyes.gouta(a)gmail.com&gt; wrote:

>  Thanks Kyle for making it available!
>
>  -Ilyes
>
>
>  On Tue, Nov 16, 2010 at 5:39 PM, Kyle McMartin <kyle(a)mcmartin.ca&gt; wrote:
>
> > On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote:
> > > Can we have this patch back ported into the current kernel for Fedora 14
> > and
> > > possibly posted as an update? :)
> > >
> > > Would be wonderful!
> > >
> >
> > Try this,
> > http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/
> > i686 coming whenever mock finishes.
> >
> > regards, Kyle.
> > --
> > devel mailing list
> > devel(a)lists.fedoraproject.org
> > https://admin.fedoraproject.org/mailman/listinfo/devel
> >
>
>

[Genes MailLists]

On 11/16/2010 11:39 AM, Kyle McMartin wrote:
>  On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote:
> > Can we have this patch back ported into the current kernel for Fedora 14 and
> > possibly posted as an update? :)
> >
> > Would be wonderful!
> >
>  
>  Try this,
>  http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/
>  i686 coming whenever mock finishes.
>  
>  regards, Kyle. 
 Testing this on f13 ... thank you ...

 So far no problems ... too soon to report on benefits



 gene

[Genes MailLists]

On 11/16/2010 11:58 AM, Genes MailLists wrote:
>  On 11/16/2010 11:39 AM, Kyle McMartin wrote:
> > On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote:
> >> Can we have this patch back ported into the current kernel for Fedora 14 and
> >> possibly posted as an update? :)
> >>
> >> Would be wonderful!
> >>
> >
> > Try this,
> > http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/
> > i686 coming whenever mock finishes.
> >
> > regards, Kyle.
>  
>   Testing this on f13 ... thank you ...
>  
>   So far no problems ... too soon to report on benefits
>  
>  
>  
>   gene 
  I am having these now :-(

Nov 16 17:00:36 lap1 kernel: [18518.537661] BUG: sleeping function
called from invalid context at mm/slub.c:1701
Nov 16 17:00:36 lap1 kernel: [18518.537665] in_atomic(): 0,
irqs_disabled(): 1, pid: 8821, name: gnome-terminal
Nov 16 17:00:36 lap1 kernel: [18518.537668] Pid: 8821, comm:
gnome-terminal Not tainted 2.6.35.8-59.xsched1.fc14.x86_64 #1
Nov 16 17:00:36 lap1 kernel: [18518.537669] Call Trace:
Nov 16 17:00:36 lap1 kernel: [18518.537677]  [<ffffffff8103d03d>]
__might_sleep+0xed/0xef
Nov 16 17:00:36 lap1 kernel: [18518.537682]  [<ffffffff811096b8>]
kmem_cache_alloc_notrace+0x37/0xb2
Nov 16 17:00:36 lap1 kernel: [18518.537685]  [<ffffffff8104af89>]
sched_autogroup_create_attach+0x26/0xe1
Nov 16 17:00:36 lap1 kernel: [18518.537689]  [<ffffffff812a21e0>]
__proc_set_tty+0x10d/0x116
Nov 16 17:00:36 lap1 kernel: [18518.537692]  [<ffffffff812a4ca4>]
tty_open+0x457/0x512
Nov 16 17:00:36 lap1 kernel: [18518.537695]  [<ffffffff8111a354>]
chrdev_open+0x122/0x143
Nov 16 17:00:36 lap1 kernel: [18518.537699]  [<ffffffff811e1e6c>] ?
selinux_dentry_open+0xee/0xf7
Nov 16 17:00:36 lap1 kernel: [18518.537701]  [<ffffffff8111a232>] ?
chrdev_open+0x0/0x143
Nov 16 17:00:36 lap1 kernel: [18518.537704]  [<ffffffff81115ef1>]
__dentry_open+0x167/0x29e
Nov 16 17:00:36 lap1 kernel: [18518.537707]  [<ffffffff811160f7>]
nameidata_to_filp+0x3f/0x50
Nov 16 17:00:36 lap1 kernel: [18518.537710]  [<ffffffff811217c5>]
do_last+0xNov 16 17:00:36 lap1 kernel: [18518.537661] BUG: sleeping
function called from invalid context at mm/slub.c:1701
Nov 16 17:00:36 lap1 kernel: [18518.537665] in_atomic(): 0,
irqs_disabled(): 1, pid: 8821, name: gnome-terminal
Nov 16 17:00:36 lap1 kernel: [18518.537668] Pid: 8821, comm:
gnome-terminal Not tainted 2.6.35.8-59.xsched1.fc14.x86_64 #1
Nov 16 17:00:36 lap1 kernel: [18518.537669] Call Trace:
Nov 16 17:00:36 lap1 kernel: [18518.537677]  [<ffffffff8103d03d>]
__might_sleep+0xed/0xef
Nov 16 17:00:36 lap1 kernel: [18518.537682]  [<ffffffff811096b8>]
kmem_cache_alloc_notrace+0x37/0xb2
Nov 16 17:00:36 lap1 kernel: [18518.537685]  [<ffffffff8104af89>]
sched_autogroup_create_attach+0x26/0xe1
Nov 16 17:00:36 lap1 kernel: [18518.537689]  [<ffffffff812a21e0>]
__proc_set_tty+0x10d/0x116
Nov 16 17:00:36 lap1 kernel: [18518.537692]  [<ffffffff812a4ca4>]
tty_open+0x457/0x512
Nov 16 17:00:36 lap1 kernel: [18518.537695]  [<ffffffff8111a354>]
chrdev_open+0x122/0x143
Nov 16 17:00:36 lap1 kernel: [18518.537699]  [<ffffffff811e1e6c>] ?
selinux_dentry_open+0xee/0xf7
Nov 16 17:00:36 lap1 kernel: [18518.537701]  [<ffffffff8111a232>] ?
chrdev_open+0x0/0x143
Nov 16 17:00:36 lap1 kernel: [18518.537704]  [<ffffffff81115ef1>]
__dentry_open+0x167/0x29e
Nov 16 17:00:36 lap1 kernel: [18518.537707]  [<ffffffff811160f7>]
nameidata_to_filp+0x3f/0x50
Nov 16 17:00:36 lap1 kernel: [18518.537710]  [<ffffffff811217c5>]
do_last+0x447/0x5b8
Nov 16 17:00:36 lap1 kernel: [18518.537713]  [<ffffffff8112320c>]
do_filp_open+0x217/0x5fe
Nov 16 17:00:36 lap1 kernel: [18518.537716]  [<ffffffff8112d9f2>] ?
mntput_no_expire+0x29/0xe4
Nov 16 17:00:36 lap1 kernel: [18518.537719]  [<ffffffff81220ad3>] ?
might_fault+0x21/0x23
Nov 16 17:00:36 lap1 kernel: [18518.537723]  [<ffffffff8112c05e>] ?
alloc_fd+0x7b/0x124
Nov 16 17:00:36 lap1 kernel: [18518.537725]  [<ffffffff81115c92>]
do_sys_open+0x63/0x10f
Nov 16 17:00:36 lap1 kernel: [18518.537728]  [<ffffffff81115d71>]
sys_open+0x20/0x22
Nov 16 17:00:36 lap1 kernel: [18518.537731]  [<ffffffff81009c72>]
system_call_fastpath+0x16/0x1b
447/0x5b8
Nov 16 17:00:36 lap1 kernel: [18518.537713]  [<ffffffff8112320c>]
do_filp_open+0x217/0x5fe
Nov 16 17:00:36 lap1 kernel: [18518.537716]  [<ffffffff8112d9f2>] ?
mntput_no_expire+0x29/0xe4
Nov 16 17:00:36 lap1 kernel: [18518.537719]  [<ffffffff81220ad3>] ?
might_fault+0x21/0x23
Nov 16 17:00:36 lap1 kernel: [18518.537723]  [<ffffffff8112c05e>] ?
alloc_fd+0x7b/0x124
Nov 16 17:00:36 lap1 kernel: [18518.537725]  [<ffffffff81115c92>]
do_sys_open+0x63/0x10f
Nov 16 17:00:36 lap1 kernel: [18518.537728]  [<ffffffff81115d71>]
sys_open+0x20/0x22
Nov 16 17:00:36 lap1 kernel: [18518.537731]  [<ffffffff81009c72>]
system_call_fastpath+0x16/0x1b

[Kyle McMartin]

On Tue, Nov 16, 2010 at 06:09:49PM -0500, Genes MailLists wrote:
>    I am having these now :-(
>   
Hi Gene,

Looks like the author hasn't run with CONFIG_DEBUG_SPINLOCK_SLEEP, as
its a problem with the patch against 2.6.37-rc2 as well (it's doing
kmalloc with irqs disabled.)

I'll let you know if there's a fix, it's not straightforward. (The
message should be fairly harmless though, just a nuisance.)

regards, Kyle

>  Nov 16 17:00:36 lap1 kernel: [18518.537661] BUG: sleeping function
>  called from invalid context at mm/slub.c:1701
>  Nov 16 17:00:36 lap1 kernel: [18518.537665] in_atomic(): 0,
>  irqs_disabled(): 1, pid: 8821, name: gnome-terminal

[Genes MailLists]

On 11/16/2010 08:34 PM, Kyle McMartin wrote:
>  On Tue, Nov 16, 2010 at 06:09:49PM -0500, Genes MailLists wrote:
> >   I am having these now :-(
> >
>  
>  Hi Gene,
>  
>  Looks like the author hasn't run with CONFIG_DEBUG_SPINLOCK_SLEEP, as
>  its a problem with the patch against 2.6.37-rc2 as well (it's doing
>  kmalloc with irqs disabled.)
>  
>  I'll let you know if there's a fix, it's not straightforward. (The
>  message should be fairly harmless though, just a nuisance.)
>  
>  regards, Kyle
>  
  Great - thanks for the feedback .. I'll keep testing ... I do have
many terminals and have lots of things running so it will be interesting
to see how it performs (feel wise).

gene/

[Gilboa Davara]

On Tue, 2010-11-16 at 11:39 -0500, Kyle McMartin wrote:
>  On Tue, Nov 16, 2010 at 04:58:11PM +0100, Ilyes Gouta wrote:
>  > Can we have this patch back ported into the current kernel for Fedora 14 and
>  > possibly posted as an update? :)
>  > 
>  > Would be wonderful!
>  > 
>  
>  Try this,
>  http://kyle.fedorapeople.org/kernel/2.6.35.8-59.xsched1/
>  i686 coming whenever mock finishes.
>  
>  regards, Kyle. 
Thanks!

I'll test it ASAP on my Xeon workstation(s). *

- Gilboa
* That suffer badly when I start too many VM's (via qemu-kvm w/ VNC
head) in the background.

[Lennart Poettering]

On Tue, 16.11.10 16:58, Ilyes Gouta (ilyes.gouta(a)gmail.com) wrote:

>  Hi,
>  
>
> http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kerne...
>  patch: http://marc.info/?l=linux-kernel&m=128978361700898&w=2
>  
>  Can we have this patch back ported into the current kernel for Fedora 14 and
>  possibly posted as an update? :) 
This appears completely backwards to me. Attaching things like this to a
TTY is just wrong, because normally we don't have a single TTY around on
most graphical sessions.

The kernel doesn't really have a notion of what a "session" is (only the
audit subsystem kinda has), but if this grouping behaviour is supposed
to be bound to a session, then attaching it to a TTY is a pretty shitty
replacement.

Dhaval Giani pointed out to me that the same can be done from userspace
simply by creating a cgroup for each session in the cpu hierarchy. Turns
out systemd actually does pretty much that, except in the named systemd
hierarchy. It is trivial modification to create a group in both hierarchies.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Ilyes Gouta]

Hi Leenart,

>  Dhaval Giani pointed out to me that the same can be done from
> userspace
>  simply by creating a cgroup for each session in the cpu hierarchy. Turns 
So a session's (as you're referring) initiator to would be the terminal
emulator process that has a virtual tty and systemd detect those and setup a
proper cgroup so that we could differentiate when scheduling with other
processes?

-Ilyes

On Tue, Nov 16, 2010 at 6:14 PM, Lennart Poettering <mzerqung(a)0pointer.de&gt;wrote:

> On Tue, 16.11.10 16:58, Ilyes Gouta (ilyes.gouta(a)gmail.com) wrote:
>
> > Hi,
> >
> >
>
http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kerne...
> > patch: http://marc.info/?l=linux-kernel&m=128978361700898&w=2
> >
> > Can we have this patch back ported into the current kernel for Fedora 14
> and
> > possibly posted as an update? :)
>
> This appears completely backwards to me. Attaching things like this to a
> TTY is just wrong, because normally we don't have a single TTY around on
> most graphical sessions.
>
> The kernel doesn't really have a notion of what a "session" is (only
the
> audit subsystem kinda has), but if this grouping behaviour is supposed
> to be bound to a session, then attaching it to a TTY is a pretty shitty
> replacement.
>
>  Dhaval Giani pointed out to me that the same can be done from
> userspace
>  simply by creating a cgroup for each session in the cpu hierarchy. Turns 
> out
systemd actually does pretty much that, except in the named systemd
> hierarchy. It is trivial modification to create a group in both
> hierarchies.
>
> Lennart
>
> --
> Lennart Poettering - Red Hat, Inc.
> --
> devel mailing list
> devel(a)lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Lennart Poettering]

On Tue, 16.11.10 19:52, Ilyes Gouta (ilyes.gouta(a)gmail.com) wrote:

>  Hi Leenart,
>  
>  > Dhaval Giani pointed out to me that the same can be done from userspace
>  > simply by creating a cgroup for each session in the cpu hierarchy. Turns
>  
>  So a session's (as you're referring) initiator to would be the terminal
>  emulator process that has a virtual tty and systemd detect those and setup a
>  proper cgroup so that we could differentiate when scheduling with other
>  processes? 
So, systemd now puts every service it starts into its own cpu cgroup (in
addition to the cgroup in the systemd cgroup it is already put in). In
the general case this is a lot more useful than binding things to a TTY,
since almost nothing that runs on a normal system actually has a
TTY. Basically only "make -j" has. man-db hasn't. update-db
hasn't. firefox hasn't. Nothing has.

I think priority should be to add finer grained group scheduling between
services and apps, and then as last step to that even between multiple
ptys that a single gnome-terminal manages, but this is not where you
should start. It's were the story ends.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Josh Stone]

On 11/16/2010 09:14 AM, Lennart Poettering wrote:
>  This appears completely backwards to me. Attaching things like this
> to a
>  TTY is just wrong, because normally we don't have a single TTY around on
>  most graphical sessions.
>  
>  The kernel doesn't really have a notion of what a "session" is (only the
>  audit subsystem kinda has), but if this grouping behaviour is supposed
>  to be bound to a session, then attaching it to a TTY is a pretty shitty
>  replacement. 
I think the TTY granularity for autogroups is *intentionally* finer than
session granularity, which is why Linus' running kbuild doesn't
interfere with the rest of his desktop.

So if we confirm that this is a win, then I hope you also make sure that
systemd's grouping doesn't interfere with autogrouping benefits.  That
could just mean that systemd explicitly does what autogroup is
implicitly doing.

Josh

[Lennart Poettering]

On Tue, 16.11.10 11:02, Josh Stone (jistone(a)redhat.com) wrote:

>  
>  On 11/16/2010 09:14 AM, Lennart Poettering wrote:
>  > This appears completely backwards to me. Attaching things like this to a
>  > TTY is just wrong, because normally we don't have a single TTY around on
>  > most graphical sessions.
>  > 
>  > The kernel doesn't really have a notion of what a "session" is (only
> the
>  > audit subsystem kinda has), but if this grouping behaviour is supposed
>  > to be bound to a session, then attaching it to a TTY is a pretty shitty
>  > replacement.
>  
>  I think the TTY granularity for autogroups is *intentionally* finer than
>  session granularity, which is why Linus' running kbuild doesn't
>  interfere with the rest of his desktop. 
See my later "patch" for that.

http://lkml.org/lkml/2010/11/16/330

>  So if we confirm that this is a win, then I hope you also make sure
> that
>  systemd's grouping doesn't interfere with autogrouping benefits.  That
>  could just mean that systemd explicitly does what autogroup is
>  implicitly doing. 
This autogrouping should just go away. I think it has little use on
anything but machines of kernel hackers, and systemd would probably turn
this off on boot fi this is compiled into the kernel.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.

[Matthew Garrett]

On Tue, Nov 16, 2010 at 06:14:33PM +0100, Lennart Poettering wrote:

>  The kernel doesn't really have a notion of what a
> "session" is (only the
>  audit subsystem kinda has), but if this grouping behaviour is supposed
>  to be bound to a session, then attaching it to a TTY is a pretty shitty
>  replacement.
>  
>  Dhaval Giani pointed out to me that the same can be done from userspace
>  simply by creating a cgroup for each session in the cpu hierarchy. Turns
>  out systemd actually does pretty much that, except in the named systemd
>  hierarchy. It is trivial modification to create a group in both hierarchies. 
That's not inherently a problem though, is it? Even if we have this 
in-kernel, systemd can disable it at startup and implement its own 
policy. It just means that the default case is (arguably) saner than it 
currently is.

-- 
Matthew Garrett | mjg59(a)srcf.ucam.org

[Michał Piotrowski]

Hi,

2010/11/16 Ilyes Gouta <ilyes.gouta(a)gmail.com&gt;:
>  Hi,
>
> http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kerne...
>  patch: http://marc.info/?l=linux-kernel&m=128978361700898&w=2
>  Can we have this patch back ported into the current kernel for Fedora 14 and
>  possibly posted as an update? :) 
Let me guess - Canonical already announced (or will do so within the
next few hours) that they will use this patch in the new Ubuntu :)

>  Would be wonderful! 
Surely this would be

>  -Ilyes
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>  
Best regards,
Michal

[Ilyes Gouta]

Hi,

I've been reading http://lkml.org/lkml/2010/11/16/402 and actually Lennart
has put some solid thoughts and arguments there and IMHO it was *somehow*
pretty convincing that this should be done at user-space, in conjunction
with tools such as systemd, albeit introducing more complexity in form of
configuration infrastructure and whatnot.

Having this being done automatically by the kernel looks really easy and yet
promising. The downside of it is that it just feels like it's something
rigged towards a special class of applications (TTY based, build jobs) and
would act behind the scene without user-space knowing (explicitly) about
this classification, cgroups being spawned and subtasks associated to them.

Still, It would be nice to have this differentiation in place, being
implemented in either forms, since it brings a certain win for the desktop
user and developer. I think having a term open for churning code is part (or
a possible user-case) of the desktop experience :)

-Ilyes

2010/11/17 Michał Piotrowski <mkkp4x4(a)gmail.com&gt;

>  Hi,
>
>  2010/11/16 Ilyes Gouta <ilyes.gouta(a)gmail.com&gt;:
>  > Hi,
>  >
>
> http://linux.slashdot.org/story/10/11/16/1330233/The-200-Line-Linux-Kerne...
>  > patch: http://marc.info/?l=linux-kernel&m=128978361700898&w=2
>  > Can we have this patch back ported into the current kernel for Fedora 14
>  and
>  > possibly posted as an update? :)
>
>  Let me guess - Canonical already announced (or will do so within the
>  next few hours) that they will use this patch in the new Ubuntu :)
>
>  > Would be wonderful!
>
>  Surely this would be
>
>  > -Ilyes
>  > --
>  > devel mailing list
>  > devel(a)lists.fedoraproject.org
>  > https://admin.fedoraproject.org/mailman/listinfo/devel
>  >
>
>  Best regards,
>  Michal
>  --
>  devel mailing list
>  devel(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/devel
>

[Josh Boyer]

On Wed, Nov 17, 2010 at 5:03 AM, Ilyes Gouta <ilyes.gouta(a)gmail.com&gt; wrote:
>  Hi,
>  I've been reading http://lkml.org/lkml/2010/11/16/402 and actually Lennart
>  has put some solid thoughts and arguments there and IMHO it was *somehow*
>  pretty convincing that this should be done at user-space, in conjunction
>  with tools such as systemd, albeit introducing more complexity in form of
>  configuration infrastructure and whatnot.
>  Having this being done automatically by the kernel looks really easy and yet
>  promising. The downside of it is that it just feels like it's something
>  rigged towards a special class of applications (TTY based, build jobs) and
>  would act behind the scene without user-space knowing (explicitly) about
>  this classification, cgroups being spawned and subtasks associated to them.
>  Still, It would be nice to have this differentiation in place, being
>  implemented in either forms, since it brings a certain win for the desktop
>  user and developer. I think having a term open for churning code is part (or
>  a possible user-case) of the desktop experience :) 
Being entirely serious, you should have sent this email on the thread
you indicated.  Sending it to this list isn't going to really benefit
the discussion that needs to happen.

josh