Kernel should use CONFIG_FAIR_CGROUP_SCHED

Although this mailing list applies to PowerPC specifically, the comments are relevant to the behavior seen with my Folding@Home process, as commented in bug 177713 and bug 178807 :
http://patchwork.ozlabs.org/linuxppc/patch?q=scheduling&id=16345
http://patchwork.ozlabs.org/linuxppc/patch?q=scheduling&id=16447
http://patchwork.ozlabs.org/linuxppc/patch?q=scheduling&id=16492
http://patchwork.ozlabs.org/linuxppc/patch?q=scheduling&id=16506
(Due to the organization of that site, I can't find a way to navigate the whole thread from one place.)

The last of the above messages indicates a patch (which is now included in Ubuntu 2.6.24-8). Do you think it will be sufficient, or do you still see a need to change the scheduler default?

As far as I understand it, CONFIG_FAIR_CGROUP_SCHED is still the preferred configuration and will provide the previous behavior by default (with only one big group for all processes). However, setup seems to be more difficult/powerful (see Documentation/cgroups.txt in the linux source).

I don't know, if it matches the requirements for Ubuntu, but you can easily create the same behavior as with CONFIG_FAIR_USER_SCHED: just create a cgroup per user, listen to the uevent "add /kernel/uids/" in udev and then put any future processes into this cgroup, where then also child processes will go.

This way, C_F_USER_SCHED could be simulated and has the better default on a desktop system.

Using the uevent interface to dynamically adjust the cpu_share (for USER_SCHED) or cpu.shares (for CGROUP_SCHED) of users (upon creation of /sys/kernel/uids/USERID) based on a configuration directory would allow to tune it.

E.g., the boinc package would install a file in /etc/cgroups-conf.d/boinc with:
user==boinc cpu_share=2
to assign the lowest possible value of cpu shares to the boinc user.

The package that installs /etc/cgroups-conf.d/ (or similar) would install a udev script to hook into the kernel uevent process. This script then would check if the added user in /sys/kernel/uids/ is listed in one of the config files and adjust the cpu.shares accordingly. (another selectors could be "group", e.g. "group=www-data").

This way, packages can provide default cpu_share values for a given user and the admin can easily adjust them.

Does it make sense to switch to using CGROUPS and provide a userland configuration package for it?

(I've not tested the two mentioned sched patches yet in the new kernel in Ubuntu)

I suggest that CONFIG_FAIR_CGROUP_SCHED be the default. Fair user scheduler can be simulated with the help of a userspace daemon posted at http://article.gmane.org/gmane.linux.kernel/553267 . You will need to make minor changes and fix some corner cases, but it is possible. CONFIG_FAIR_USER_SCHED hides a lot of the capability of the group scheduler and also forces its use. CONFIG_FAIR_CGROUP_SCHED is more flexible, allows arbitrary grouping of processes.

AFAIK there is no uevent generated in user creation for !C_F_U_S.

Thanks,
Dhaval

A situation for which the currently configured kernel is poor is the following:

- a single-user desktop machine
- runs a scripted daily backup using, eg, tar and bz2 compression.

The backup script needs to run as root, to access files system wide. Because of the compression stage, the backup script is CPU intensive. The user's script runs with a large "nice" value. In the present configuration, although the user's desktop remains responsive while the backup runs, the backup process running as root takes a significant share of the CPU time, and affects any CPU-intensive task the user is running. If the kernel is recompiled with CONFIG_FAIR_CGROUP_SCHED, then the "nice" value has the desired effect and the backup script is unobstrusive.

I have verified this using hardy's 2.6.24-10-generic. Recompiling with CONFIG_FAIR_CGROUP_SCHED greatly increased the CPU share that the user's processes were given while the backup was running.

Anyway, the point of this post is to point out that things like boinc are far from the only cases where the present config has a downside. And unlike the boinc case, a systemwide backup cannot so easily be run as another user.

I'm marking this as "High priority" now, because it's in fact a regression.
Changing this is quite simple even.

I'm setting CGROUPS for the x86/x86_64 server flavour as well as all of the sparc/powerpc/hppa/ia64 flavours. Changing the desktop default at this late stage is seen as too risky. This is definitely a topic that needs some discussion at UDS, particularly in light of the application space tools required to simulate USER_SCHED under CGROUPS (if necessary).

On Tue, Apr 1, 2008 at 9:55 PM, Tim Gardner <email address hidden> wrote:
> I'm setting CGROUPS for the x86/x86_64 server flavour as well as all of
> the sparc/powerpc/hppa/ia64 flavours. Changing the desktop default at
> this late stage is seen as too risky. This is definitely a topic that
> needs some discussion at UDS, particularly in light of the application
> space tools required to simulate USER_SCHED under CGROUPS (if
> necessary).
>

I believe it to be more dangerous to run USER_SCHED as there will be
performance regressions since the behaviour will change as shown in
the boinc thread. (Though technically it is not a regression). Please
consider moving to CGROUP. USER_SCHED can be simulated in CGROUP using
a daemon posted at http://article.gmane.org/gmane.linux.kernel/553267
). Note that it will have to modified a bit since containers has since
been renamed to cgroup. I think I have a modified version of the same
lying around somewhere. If I find it I can send it to you.

Thanks
dhaval

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=0449bec8d65228242bd5f9f9294ae3c37d4dbb34

Note that sparc/powerpc/ia64/hppa do not support CONFIG_FAIR_CGROUP_SCHED.

On Tue, Apr 1, 2008 at 10:11 PM, Tim Gardner <email address hidden> wrote:
> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-
> hardy.git;a=commit;h=0449bec8d65228242bd5f9f9294ae3c37d4dbb34
>
> Note that sparc/powerpc/ia64/hppa do not support
> CONFIG_FAIR_CGROUP_SCHED.
>

Wrong. I am sure powerpc and ia64 support C_F_C_S. It is arch
independent. Where can I clone your sources from?

Thanks,
Dhaval

This bug was fixed in the package linux - 2.6.24-14.24

---------------
linux (2.6.24-14.24) hardy; urgency=low

  [Amit Kucheria]

  * LPIA: Update from moblin
  * LPIA: Fix reboot problem after S3/S4
  * LPIA: Integrate latest Dabney thermal patches
  * LPIA: Change-umd_dbg-debug-level-to-KERN_INFO
  * LPIA: Compile modules into kernel to save on boot time
  * LPIA: lots of Dabney CONFIG options dissapeared
  * LPIA: Purge nonexistent config options

  [Jay Chetty]

  * UBUNTU:USBC:Integrated USBC 2.0.0.32L.0009

  [Misha Zhilin]

  * USB: ehci: handle large bulk URBs correctly (again)
    - LP: #204857

  [Tim Gardner]

  * frame buffer regression - screen blank except for blinking cursor after
    fbcon vtswitch
    - LP: #201591
  * Blacklist Bluetooth Dell Wireless 370 for SCO MTU
    - LP: #209715
  * Set CONFIG_FAIR_CGROUP_SCHED for server flavours.
    - LP: #188226
  * Add DMI IO_DELAY support.
    - LP: #200057

 -- Tim Gardner <email address hidden> Mon, 31 Mar 2008 11:19:49 -0600

On Tue, Apr 1, 2008 at 10:37 PM, Dhaval Giani <email address hidden> wrote:
> On Tue, Apr 1, 2008 at 10:11 PM, Tim Gardner <email address hidden> wrote:
> > http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-
> > hardy.git;a=commit;h=0449bec8d65228242bd5f9f9294ae3c37d4dbb34
> >
> > Note that sparc/powerpc/ia64/hppa do not support
> > CONFIG_FAIR_CGROUP_SCHED.
> >
>
> Wrong. I am sure powerpc and ia64 support C_F_C_S. It is arch
> independent. Where can I clone your sources from?
>

Hi,

Can I get more details on this?

Thanks,
Dhaval

Re-opening as discussed on IRC with dhaval and Tim.

For the record: CONFIG_FAIR_CGROUP_SCHED is arch independent.

As dhaval pointed out, using cgroups (and the previous behaviour) would save us a lot of bug reports in the future, like e.g. bug 177713, where a process running in the background gets 50% of all cpu cycles at least.

I repeat, using CONFIG_FAIR_USER_SCHED is especially bad on the desktop: processes running as another user (especially root, which gets twice as much cpu shares as other users by default) will slow the current user's processes down.

With cgroups, you _can_ put a daemon in place, but you don't have to.
Using cgroups without any daemon/hooking will just result in the pre-Hardy behavior: all processes are in the same pool for cpu shares.
But, in contrast to CONFIG_FAIR_USER_SCHED, CONFIG_FAIR_CGROUP_SCHED allows much finer control of resources, if you want to setup this manually.

Enabled CGROUPS for non-x86/x86_64 arches, all flavours. Missed the correct setting the first time around.

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=e06598b264105050b9ddf60416624a495b831450

This bug was fixed in the package linux - 2.6.24-15.26

---------------
linux (2.6.24-15.26) hardy; urgency=low

  [Colin Ian King]

  * airprime.c supports more devices
    - LP: #208250

  [Kees Cook]

  * AppArmor: get latest batch of upstream fixes into Hardy (svn 1160)

  [Stefan Bader]

  * ACPI: fix boot oops regression in kernel
    - LP: #207014

  [Tim Gardner]

  * Enable CGROUPS for non x86/x86_64 arches, all flavours.
   - LP: #188226

 -- Tim Gardner <email address hidden> Thu, 03 Apr 2008 07:00:29 -0600

Reopening again, CONFIG_FAIR_CGROUP_SCHED is still not set in 2.6.24-15-generic.

x86 and generic flavours still don't have CONFIG_FAIR_CGROUP_SCHED set.

-generic and -i386 flavours will remain CONFIG_FAIR_USER_SCHED. Use the -server flavour for CONFIG_FAIR_CGROUP_SCHED.

But CONFIG_FAIR_USER_SCHED causes _desktop_ regressions! Why is CGROUP_SCHED being considered the risky change, when it's the default upstream, and USER_SCHED is the option that changes behaviour from previous kernels?

On Tue, Apr 8, 2008 at 9:18 AM, cwillu <email address hidden> wrote:
> But CONFIG_FAIR_USER_SCHED causes _desktop_ regressions! Why is
> CGROUP_SCHED being considered the risky change, when it's the default
> upstream, and USER_SCHED is the option that changes behaviour from
> previous kernels?
>

upstream default is USER_SCHED to give it more testing. But yes, the
recommended option is CGROUP_SCHED

Dhaval

Sorry, I should have said mainline kernel, not [debian] upstream.

But yes, "... to give it more testing" doesn't give me a warm fuzzy feeling :p

Is it possible to disable the group scheduler completely (both
FAIR_CGROUP and FAIR_USER off)?

Otherwise I really suspect the current config is going to cause varied
minor but widespread issues. Your printer requires a software
rasterizer? The desktop will get laggy when you print. Copying some
big files to another machine via nautilus sftp://? The sshd process
will start hurting interactivity. Nicing doesn't help either of those
cases. Try using /sys/kernel/uids/*/cpu_share instead? (and do we
really expect users to figure that out?) Oops, now xorg doesn't get
enough processor time to keep the gui running smoothly, but only if
you're using certain video chipsets that have Xorg drivers that don't
off-load certain tasks to the videocard. All issues I've run into
since updating to hardy (after using cfs and ck's sd and staircase
schedulers for years alongside stock ubuntu and mainline kernels,
without any of these issues). :)

Nicing apt and updatedb no
longer does the obvious thing, while cpu_share ends up being far too
broad: either apps get choppy because they can't run, or they get
choppy because Xorg can't run.

Don't get me wrong, I _very_ happy that we're finally running a cfs
kernel by default, but I'd be surprised if I've exhaustively
enumerated all the interactions caused by what seems to be an
afterthought.

I can't think of any workload other than a server where a simple uid
based approach would be close to the right thing, and yet here we are,
with the server install being the only x86 kernel with the ability to
do anything but the uid approach, and the known regressions in the
generic kernel not being fixed because of non-specific concerns of
regressions, caused by, what, reverting to the old behaviour?

I seem to have seen this one already.

On Tue, Apr 8, 2008 at 8:23 PM, cwillu <email address hidden> wrote:
> Is it possible to disable the group scheduler completely (both
> FAIR_CGROUP and FAIR_USER off)?
>
>
> Otherwise I really suspect the current config is going to cause varied
> minor but widespread issues. Your printer requires a software
> rasterizer? The desktop will get laggy when you print. Copying some
> big files to another machine via nautilus sftp://? The sshd process
> will start hurting interactivity. Nicing doesn't help either of those
> cases. Try using /sys/kernel/uids/*/cpu_share instead? (and do we
> really expect users to figure that out?) Oops, now xorg doesn't get
> enough processor time to keep the gui running smoothly, but only if
> you're using certain video chipsets that have Xorg drivers that don't
> off-load certain tasks to the videocard. All issues I've run into
> since updating to hardy (after using cfs and ck's sd and staircase
> schedulers for years alongside stock ubuntu and mainline kernels,
> without any of these issues). :)
>
>
> Nicing apt and updatedb no
> longer does the obvious thing, while cpu_share ends up being far too
> broad: either apps get choppy because they can't run, or they get
> choppy because Xorg can't run.
>
>
> Don't get me wrong, I _very_ happy that we're finally running a cfs
> kernel by default, but I'd be surprised if I've exhaustively
> enumerated all the interactions caused by what seems to be an
> afterthought.
>
>
> I can't think of any workload other than a server where a simple uid
> based approach would be close to the right thing, and yet here we are,
> with the server install being the only x86 kernel with the ability to
> do anything but the uid approach, and the known regressions in the
> generic kernel not being fixed because of non-specific concerns of
> regressions, caused by, what, reverting to the old behaviour?
>
>
>
> --
> Kernel should use CONFIG_FAIR_CGROUP_SCHED
> https://bugs.launchpad.net/bugs/188226
> You received this bug notification because you are a direct subscriber
> of the bug.
>

btw: I've tried the -server images already for this very reason a few days ago: First I had to manually install l-r-m/nvidia-glx-new for it and then the infamous "black window" bug appeared after about 10 open windows already (while I have not seen it on -generic for a long while).
So, "just using the server" image does not seem to be a good solution to work around this regression, IMHO.

I've tried to get the kernel teams attention for (the impact of) this issue a few days after 2.6.24 was available in Hardy and I've found out that the USER_SCHED setting was the reason for boinc causing my system to crawl.
While there's a workaround for boinc now (luckily), it makes Hardy unusable for any other kind of distributed computing clients (by default) or causes issues like outlined above.

Tim, I've thought you were about to enable cgroups for all kernel flavors, after we've talked to you on #ubuntu-kernel a few days ago?!

On Tue, Apr 8, 2008 at 10:36 PM, Daniel Hahler <email address hidden> wrote:
> btw: I've tried the -server images already for this very reason a few days ago: First I had to manually install l-r-m/nvidia-glx-new for it and then the
> infamous "black window" bug appeared after about 10 open windows already (while I have not seen it on -generic for a long while).

I am sorry, is this because of nvidia or is it because of the cgroup_sched?

> So, "just using the server" image does not seem to be a good solution to work around this regression, IMHO.
>
> I've tried to get the kernel teams attention for (the impact of) this issue a few days after 2.6.24 was available in Hardy and I've found out that the
> USER_SCHED setting was the reason for boinc causing my system to crawl.
> While there's a workaround for boinc now (luckily), it makes Hardy unusable for any other kind of distributed computing clients (by default) or causes
> issues like outlined above.
>

Well you can use the same workaround for all these other distributed
computing clients as well.

> Tim, I've thought you were about to enable cgroups for all kernel
> flavors, after we've talked to you on #ubuntu-kernel a few days ago?!
>

I too hope you shift to cgroup based scheduling as soon as possible.

Thanks
Dhaval

Re-opening, because it's only fixed for "-server".
Please close it as "Won't fix" or add a Hardy task and close it as "Won't fix" instead..

dhaval, no, "the black window bug" is unrelated to cgroups (it's caused by not handling graphic card memory correctly AFAIK). I just wanted to make the point that the proposed "workaround" does not work for me.

I'm getting reports of UI unresponsiveness, and I am able to reproduce it.
Please, can you get this addressed before release?

It seems this issue break synergy and make it totally unusable: bug #194029

disabling FAIR_GROUP_SCHED fixes the synergy's issues.

What will be done to make synergy works?

Just browsed Fedora's kernel cvs dir and the config seems to enable this.

<snip>
CONFIG_SCHEDSTATS=y
CONFIG_SCHED_DEBUG=y
CONFIG_FAIR_GROUP_SCHED=y
CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
CONFIG_GROUP_SCHED=y
CONFIG_RT_GROUP_SCHED=y
CONFIG_CGROUP_SCHED=y
# CONFIG_CGROUP_MEM_RES_CTLR is not set
<snip>

I realize that we are too close to release, but this information may be useful for Ibex.

I ran a comparison between -generic and -server kernel, my testcase is in comment #104 of bug #192888. In a nutshell, the generic kernel causes pulseaudio to stutter when playing multiple streams, but the server kernel does not. It appears to be much more robust at handling multitasking whilst providing stutter-free audio.

My apologies, I meant comment #106 in the previous entry.

It seems that CONFIG_FAIR_CGROUP_SCHED may play a part in this difference. Testing was done on my desktop system, but unfortunately the -server kernel refuses to boot on my Dell Inspiron 510m laptop which I primarily use (complains about missing CPU feature 0:6, IIRC).

Can someone explain to me why a regression known to cause stuttering sound is not considered a show-stopper?

It will be fixed in Interpid. You get also few regressions more for free!

Yep, I'm sarcastic but really, it looks like devs will not fix it, and in a few days they will say that it does not compliment with SRU policy.

And soon somebody with code of conduct will popout - becouse some people will want to have bug fixed.

How is this not getting fixed? It's going to cause major issues for a lot of desktop users, almost all if it causes stuttering sound.

If there's not enough time to fix it then delay the release. Seriously. This basically breaks Ubuntu for 99% of users.

What is the official status on this bug?

It seems to affects desktop applications, causing regression (eg: synergy is unusable bug #194029 ).

The official ubuntu release is really soon now and we have no answer about theses bugs.

http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=273f7b551a420580307fa414fe616f0e276a4035

Hi Tim,

Thanks for going ahead and making the change. Now this means thta all
flavours of ubuntu have FAIR_CGROUP_SCHED enabled by default?

Dhaval

As i understand it, the fix won't be available before 8.04.1.

I hope i'm mistaken.

The fix will most certainly feature in 8.04.1, but that doesn't
necessarily mean it will not be available as a regular update before.
Ubuntu 8.04.1 can simply be thought of as a set of rebuilt ISOs to
shave of the bugs that might have been left out.
Someone correct me if I am wrong.

SRU Justification:

Impact: Audio and Video artifacts while system is under load, such as with trackerd or updatedb.

Fix Description: The 8.04 scheduler algorithm selected for x86/x86_64 -generic is USER_SCHED. CGROUP_SCHED is much better at load leveling between process groups. The -server flavour has used CGROUP_SCHED from the beginning and has been shown to not have this issue.

Patch: http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commit;h=273f7b551a420580307fa414fe616f0e276a4035

TEST CASE: Start a test sound using gnome-sound-properties (System/Preferences/Sound, select Sound Events Test). As another user (root) run 'find / -type f | xargs grep foobar'. Audio clicks and pops can be heard in some cases.

Accepted into hardy-proposed.

I really do wish that desktop responsiveness gets the same attention in the future.
Going from a clean install of gutsy to a clean install of hardy felt like going from win 3.11 to Vista.

Like the majority of the users, I assumed it was related to some hardware configuration; perhaps the binary NVidia driver; perhaps bugs in Compiz; I also assumed that pulseaudio support, since it is new, just had some initial quirks.

To learn that it is a system-wide issue; effecting _everyone_ is a little surpising.

Can we file bug against the quality control protocol in place? To prevent these huge regressions in the future?
It's hard to imagine those responsible for the kernel didn't notice this. Desktop responsiveness should be a top priority. Perhaps the kernel developpers make less use of the multimedia features themselves? Too much work and too little play? Ifso, the solution seems simple; mandatory play-time!

In 2.6.24-17, the realtime kernels are still not using CGROUP_SCHED. Surely, that should have been the first ones fixed for multimedia!

Due to this, my playback of 720p files was terribly hampered.

Can I ask, as a regular desktop user, when will the final patch be rolled out to the normal repos? I don't want to recompile my kernel.

As another desktop user, with little Linux experience, I also support the request for a final patch soon. I'm running Hardy upgrade from Gutsy, and never had any sound or video problems prior to that upgrade. Now, any time my processor hits 100% for any reason, the music just stops and then restarts. The duration varies from milliseconds (clicks, grates and pops) to up to a full second of silence! I've fiddled with my pulseaudio settings and this changes the characteristics of the problem, but not the existence of it.

If it is any help to anyone, the gaps in the audio often coincide with the flickering at one second intervals of the "Manual network configuration" icon in the panel, which also didn't used to happen.

2.6.24-16-generic
AMD Athlon XP1600+
EnvyNG GeForce MX2 400 (64Mb)

On Sat, May 3, 2008 at 5:43 PM, Ian M. Stewart <email address hidden> wrote:
> As another desktop user, with little Linux experience, I also support
> the request for a final patch soon. I'm running Hardy upgrade from
> Gutsy, and never had any sound or video problems prior to that upgrade.
> Now, any time my processor hits 100% for any reason, the music just
> stops and then restarts. The duration varies from milliseconds (clicks,
> grates and pops) to up to a full second of silence! I've fiddled with
> my pulseaudio settings and this changes the characteristics of the
> problem, but not the existence of it.
>
> If it is any help to anyone, the gaps in the audio often coincide with
> the flickering at one second intervals of the "Manual network
> configuration" icon in the panel, which also didn't used to happen.
>
> 2.6.24-16-generic
> AMD Athlon XP1600+
> EnvyNG GeForce MX2 400 (64Mb)
>

For the time being, please go and change to shares of all users apart
from your one to 2. You can do that by changing the value in
/sys/kernels/uid/<uid>/cpu_shares. You can make it permanent by using
udev scripts if you want to.

Dhaval

Ian & dhaval,

Kernel 2.6.24-17-generic is already in the repositories. You just need to enable the "hardy-proposed" repository via Synaptic.

If you still have problems with audio, it may not be due to the scheduler. In that case, see bug #190754.

On May 3, 2008, at 7:45 AM, Conn wrote:

> Kernel 2.6.24-17-generic is already in the repositories. You just need
> to enable the "hardy-proposed" repository via Synaptic.
>

Yes, but 2.6.24-17-rt does not include the fix committed for
2.6.24-17-generic. Please include it in 2.6.24-18-rt forthwith. Thanx

On Sat, May 3, 2008 at 8:15 PM, Conn <email address hidden> wrote:
> Ian & dhaval,
>
> Kernel 2.6.24-17-generic is already in the repositories. You just need
> to enable the "hardy-proposed" repository via Synaptic.
>
> If you still have problems with audio, it may not be due to the
> scheduler. In that case, see bug #190754.
>

It should not be due to the scheduler, I agree, but the scheduler can
easily be eliminated by changing shares of the other users. If it
makes a difference, then it can be due to the scheduler.

Dhaval

Please address this problem asap. I'm running background tasks (nice 19) as different users and that makes the whole system a lot slower for everyone. I would normally expect that nice 19 tasks doesn't use any cpu when it's required for other processes.

It's very interesting to have the ability to change the way the scheduler assign CPU time but this change is so fundamental that it shouldn't be the default!

Daniel, the config for the realtime kernel has now been changed, too (in the Ubuntu kernel repo):
http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-hardy.git;a=commitdiff;h=fc9551a9b5f75ee747184d93df83b5642597eed6

Great! So, how long 'til -18?

I'd just like to verify with the -proposed kernel, UI interactivity for a user who is generating high load is drastically improved compared to stock Hardy...

thanks John, marking as verification-done since UI interactivity is reported to be better and there are no indications of regressions.

Tested on i386 on 2 different installs successfully

I have issues with sound myself, sometimes simple actions like minizing and maximizing a window can inturrept the music I play with amarok.

I just enabled the updates from "hardy-proposed" and at least on my system without too deep testings it seems that it has a very positive effect on sound, much more clean and until now no pops and clicks like before.

I've been running the proposed kernel for several weeks now on my laptop (Dell 1420N with encrypted LVM) and it is much more responsive.

Same here. I've been running the new kernel and now recommend it to people in forums. It's a no brainer, really. Hardy is much more responsive with the kernel in proposed. I'd really recommend pushing it out as an upgrade now.

Lots of folks out there in other forums are complaining about Hardy and the fix is sitting there waiting for them to find it.

There seems to be another problem now, in that the cgroup filesystem (mounted via mount -t cgroup none /dev/cgroup) complains ("No space left on device") when assigning tasks to new groups.

On Sat, May 24, 2008 at 1:48 PM, cwillu <email address hidden> wrote:
> There seems to be another problem now, in that the cgroup filesystem
> (mounted via mount -t cgroup none /dev/cgroup) complains ("No space left
> on device") when assigning tasks to new groups.
>

Root can assign tasks. Please do so as root. You can use chown on the
tasks file to change owner and allow that owner to attach tasks.

Dhaval

Oops, nevermind. Have to echo 0 to cpus and mems before it'll work.

Doesn't seem to allow more than one task to be added:

root@dominubuntu:/dev/cpuset# ls
cpuacct.usage cpuset.memory_pressure_enabled ff
cpuset.cpu_exclusive cpuset.memory_spread_page notify_on_release
cpuset.cpus cpuset.memory_spread_slab pulse
cpuset.mem_exclusive cpuset.mems releasable
cpuset.memory_migrate cpuset.sched_load_balance release_agent
cpuset.memory_pressure cpu.shares tasks
root@dominubuntu:/dev/cpuset# mkdir test
root@dominubuntu:/dev/cpuset# cd test
root@dominubuntu:/dev/cpuset/test# echo 0 > cpuset.cpus
root@dominubuntu:/dev/cpuset/test# echo 0 > cpuset.mems
root@dominubuntu:/dev/cpuset/test# echo $$ > tasks
root@dominubuntu:/dev/cpuset/test# echo 6781 > tasks
bash: echo: write error: Operation not permitted

On Sat, May 24, 2008 at 3:09 PM, cwillu <email address hidden> wrote:
> Doesn't seem to allow more than one task to be added:
>
> root@dominubuntu:/dev/cpuset# ls
> cpuacct.usage cpuset.memory_pressure_enabled ff
> cpuset.cpu_exclusive cpuset.memory_spread_page notify_on_release
> cpuset.cpus cpuset.memory_spread_slab pulse
> cpuset.mem_exclusive cpuset.mems releasable
> cpuset.memory_migrate cpuset.sched_load_balance release_agent
> cpuset.memory_pressure cpu.shares tasks
> root@dominubuntu:/dev/cpuset# mkdir test
> root@dominubuntu:/dev/cpuset# cd test
> root@dominubuntu:/dev/cpuset/test# echo 0 > cpuset.cpus
> root@dominubuntu:/dev/cpuset/test# echo 0 > cpuset.mems
> root@dominubuntu:/dev/cpuset/test# echo $$ > tasks
> root@dominubuntu:/dev/cpuset/test# echo 6781 > tasks
> bash: echo: write error: Operation not permitted
>

cat /proc/mounts. If you have mounted ns as well, that would explain it.

And use mount -t cgroup -o cpu none /cgroup to mount the group scheduler.

Thanks
Dhaval

linux 2.6.24-17.31 copied to hardy-updates.

CONFIG_FAIR_GROUP_SCHED is the Intrepid default.

Hi!

 My pulseaudio stuttering problem solved by adding myself to the pulse-rt group by entering:

sudo usermod -a -G pulse-rt $USER

Afterthat: log out and log in.

My soundcard:

$lspci | grep audio
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev a2)

Roti