Kernel should use CONFIG_FAIR_CGROUP_SCHED
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
linux (Ubuntu) |
Fix Released
|
Medium
|
Tim Gardner | ||
Hardy |
Fix Released
|
Medium
|
Tim Gardner | ||
Intrepid |
Fix Released
|
Medium
|
Tim Gardner |
Bug Description
The ubuntu kernel should use CONFIG_
The CFS (completely fair scheduler) is configured with CONFIG_
According to dhaval in bug 177713:
CONFIG_
with the option not to use by not making any groups and putting
everything in just one group.
So using CONFIR_
See also http://
I'd like to address this issue, so that e.g. boinc is usable again and does not take half of the cpu slices at least.
Changed in linux: | |
importance: | Undecided → Wishlist |
description: | updated |
Dana Goyette (danagoyette) wrote : | #1 |
Changed in linux: | |
assignee: | nobody → ubuntu-kernel-team |
status: | New → Triaged |
Tim Gardner (timg-tpi) wrote : | #2 |
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?
Changed in linux: | |
assignee: | ubuntu-kernel-team → timg-tpi |
status: | Triaged → In Progress |
Daniel Hahler (blueyed) wrote : | #3 |
As far as I understand it, CONFIG_
I don't know, if it matches the requirements for Ubuntu, but you can easily create the same behavior as with CONFIG_
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/
E.g., the boinc package would install a file in /etc/cgroups-
user==boinc cpu_share=2
to assign the lowest possible value of cpu shares to the boinc user.
The package that installs /etc/cgroups-
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)
dhaval (dhaval-giani) wrote : | #4 |
I suggest that CONFIG_
AFAIK there is no uevent generated in user creation for !C_F_U_S.
Thanks,
Dhaval
Changed in linux: | |
milestone: | none → ubuntu-8.04 |
mannheim (kronheim) wrote : | #5 |
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_
I have verified this using hardy's 2.6.24-10-generic. Recompiling with CONFIG_
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.
Daniel Hahler (blueyed) wrote : | #6 |
I'm marking this as "High priority" now, because it's in fact a regression.
Changing this is quite simple even.
Changed in linux: | |
importance: | Wishlist → High |
Changed in linux: | |
assignee: | timg-tpi → ben-collins |
Tim Gardner (timg-tpi) wrote : | #7 |
I'm setting CGROUPS for the x86/x86_64 server flavour as well as all of the sparc/powerpc/
Changed in linux: | |
assignee: | ben-collins → timg-tpi |
dhaval (dhaval-giani) wrote : Re: [Bug 188226] Re: Kernel should use CONFIG_FAIR_CGROUP_SCHED | #8 |
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/
> 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://
). 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
Tim Gardner (timg-tpi) wrote : | #9 |
Note that sparc/powerpc/
Changed in linux: | |
status: | In Progress → Fix Committed |
dhaval (dhaval-giani) wrote : | #10 |
On Tue, Apr 1, 2008 at 10:11 PM, Tim Gardner <email address hidden> wrote:
> http://
> hardy.git;
>
> Note that sparc/powerpc/
> CONFIG_
>
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
Launchpad Janitor (janitor) wrote : | #11 |
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-
* 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:
[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_
- LP: #188226
* Add DMI IO_DELAY support.
- LP: #200057
-- Tim Gardner <email address hidden> Mon, 31 Mar 2008 11:19:49 -0600
Changed in linux: | |
status: | Fix Committed → Fix Released |
dhaval (dhaval-giani) wrote : | #12 |
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://
> > hardy.git;
> >
> > Note that sparc/powerpc/
> > CONFIG_
> >
>
> 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
Daniel Hahler (blueyed) wrote : | #13 |
Re-opening as discussed on IRC with dhaval and Tim.
For the record: CONFIG_
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_
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_
Changed in linux: | |
status: | Fix Released → Triaged |
Tim Gardner (timg-tpi) wrote : | #14 |
Enabled CGROUPS for non-x86/x86_64 arches, all flavours. Missed the correct setting the first time around.
Changed in linux: | |
status: | Triaged → Fix Committed |
Launchpad Janitor (janitor) wrote : | #15 |
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
Changed in linux: | |
status: | Fix Committed → Fix Released |
Daniel Hahler (blueyed) wrote : | #16 |
Reopening again, CONFIG_
Changed in linux: | |
status: | Fix Released → Triaged |
Carey Underwood (cwillu) wrote : | #17 |
x86 and generic flavours still don't have CONFIG_
Tim Gardner (timg-tpi) wrote : | #18 |
-generic and -i386 flavours will remain CONFIG_
Changed in linux: | |
status: | Triaged → Fix Released |
Carey Underwood (cwillu) wrote : | #19 |
But CONFIG_
dhaval (dhaval-giani) wrote : | #20 |
On Tue, Apr 8, 2008 at 9:18 AM, cwillu <email address hidden> wrote:
> But CONFIG_
> 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
Carey Underwood (cwillu) wrote : | #21 |
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
Carey Underwood (cwillu) wrote : | #22 |
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/
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?
dhaval (dhaval-giani) wrote : | #23 |
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/
> 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_
> https:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>
Daniel Hahler (blueyed) wrote : | #24 |
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-
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?!
dhaval (dhaval-giani) wrote : | #25 |
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-
> 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
Daniel Hahler (blueyed) wrote : | #26 |
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.
Changed in linux: | |
status: | Fix Released → Triaged |
Flávio Martins (flavioxmartins) wrote : | #27 |
I'm getting reports of UI unresponsiveness, and I am able to reproduce it.
Please, can you get this addressed before release?
Sebastien Estienne (sebest) wrote : | #28 |
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?
Flávio Martins (flavioxmartins) wrote : | #29 |
Just browsed Fedora's kernel cvs dir and the config seems to enable this.
<snip>
CONFIG_SCHEDSTATS=y
CONFIG_
CONFIG_
CONFIG_
CONFIG_
CONFIG_
CONFIG_
# CONFIG_
<snip>
Conn O Griofa (psyke83) wrote : | #30 |
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.
Conn O Griofa (psyke83) wrote : | #31 |
My apologies, I meant comment #106 in the previous entry.
It seems that CONFIG_
ArbitraryConstant (anthony-spamtrap) wrote : | #32 |
Can someone explain to me why a regression known to cause stuttering sound is not considered a show-stopper?
Baronek (baronek1) wrote : | #33 |
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.
abingham (abingham) wrote : | #34 |
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.
Sebastien Estienne (sebest) wrote : | #35 |
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.
Changed in linux: | |
assignee: | timg-tpi → canonical-kernel-team |
Tim Gardner (timg-tpi) wrote : | #36 |
Changed in linux: | |
assignee: | canonical-kernel-team → timg-tpi |
importance: | High → Low |
milestone: | ubuntu-8.04 → ubuntu-8.04.1 |
status: | Triaged → Fix Committed |
dhaval (dhaval-giani) wrote : | #37 |
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
Sebastien Estienne (sebest) wrote : | #38 |
As i understand it, the fix won't be available before 8.04.1.
I hope i'm mistaken.
Flávio Martins (flavioxmartins) wrote : | #39 |
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.
Tim Gardner (timg-tpi) wrote : | #40 |
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.
TEST CASE: Start a test sound using gnome-sound-
Colin Watson (cjwatson) wrote : | #41 |
Accepted into hardy-proposed.
Ralf Nieuwenhuijsen (ralf-nieuwenhuijsen) wrote : | #42 |
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!
Daniel Gimpelevich (daniel-gimpelevich) wrote : | #43 |
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!
Changed in linux: | |
status: | Fix Committed → In Progress |
Lucas Cardoso (lcardoso) wrote : | #44 |
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.
Ian M. Stewart (ims) wrote : | #45 |
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)
dhaval (dhaval-giani) wrote : | #46 |
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/
udev scripts if you want to.
Dhaval
Conn O Griofa (psyke83) wrote : | #47 |
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.
Daniel Gimpelevich (daniel-gimpelevich) wrote : | #48 |
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
dhaval (dhaval-giani) wrote : | #49 |
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
Thomas Guyot-Sionnest (dermoth) wrote : | #50 |
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 Hahler (blueyed) wrote : | #51 |
Daniel, the config for the realtime kernel has now been changed, too (in the Ubuntu kernel repo):
http://
Daniel Gimpelevich (daniel-gimpelevich) wrote : | #52 |
Great! So, how long 'til -18?
Changed in linux: | |
status: | In Progress → Fix Committed |
John Dong (jdong) wrote : | #53 |
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...
Steve Langasek (vorlon) wrote : | #54 |
thanks John, marking as verification-done since UI interactivity is reported to be better and there are no indications of regressions.
Changed in linux: | |
assignee: | nobody → timg-tpi |
importance: | Undecided → Medium |
milestone: | none → ubuntu-8.04.1 |
status: | New → Fix Committed |
importance: | Low → Medium |
milestone: | ubuntu-8.04.1 → none |
status: | Fix Committed → Triaged |
Steven Harms (sharms) wrote : | #55 |
Tested on i386 on 2 different installs successfully
István Miklós Antal (djdarkmanx) wrote : | #56 |
I have issues with sound myself, sometimes simple actions like minizing and maximizing a window can inturrept the music I play with amarok.
mihai.ile (mihai.ile) wrote : | #57 |
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.
Brian Pitts (bpitts) wrote : | #58 |
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.
Matthew Tighe (tighem) wrote : | #59 |
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.
Carey Underwood (cwillu) wrote : | #60 |
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.
dhaval (dhaval-giani) wrote : | #61 |
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
Carey Underwood (cwillu) wrote : | #62 |
Oops, nevermind. Have to echo 0 to cpus and mems before it'll work.
Carey Underwood (cwillu) wrote : | #63 |
Doesn't seem to allow more than one task to be added:
root@dominubunt
cpuacct.usage cpuset.
cpuset.
cpuset.cpus cpuset.
cpuset.
cpuset.
cpuset.
root@dominubunt
root@dominubunt
root@dominubunt
root@dominubunt
root@dominubunt
root@dominubunt
bash: echo: write error: Operation not permitted
dhaval (dhaval-giani) wrote : | #64 |
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@dominubunt
> cpuacct.usage cpuset.
> cpuset.
> cpuset.cpus cpuset.
> cpuset.
> cpuset.
> cpuset.
> root@dominubunt
> root@dominubunt
> root@dominubunt
> root@dominubunt
> root@dominubunt
> root@dominubunt
> 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
Martin Pitt (pitti) wrote : | #65 |
linux 2.6.24-17.31 copied to hardy-updates.
Changed in linux: | |
status: | Fix Committed → Fix Released |
Tim Gardner (timg-tpi) wrote : | #66 |
CONFIG_
Changed in linux: | |
assignee: | timg-tpi → nobody |
status: | Triaged → Fix Released |
assignee: | timg-tpi → nobody |
Hrotkó Gábor (roti-al) wrote : | #67 |
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
Changed in linux: | |
assignee: | nobody → timg-tpi |
assignee: | nobody → timg-tpi |
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 : patchwork. ozlabs. org/linuxppc/ patch?q= scheduling& id=16345 patchwork. ozlabs. org/linuxppc/ patch?q= scheduling& id=16447 patchwork. ozlabs. org/linuxppc/ patch?q= scheduling& id=16492 patchwork. ozlabs. org/linuxppc/ patch?q= scheduling& id=16506
http://
http://
http://
http://
(Due to the organization of that site, I can't find a way to navigate the whole thread from one place.)