Bug 113713 - Kernel is not optimal for desktop systems
Summary: Kernel is not optimal for desktop systems
Status: RESOLVED WONTFIX
Alias: None
Product: SUSE LINUX 10.0
Classification: openSUSE
Component: Basesystem (show other bugs)
Version: Beta 2
Hardware: i686 All
: P5 - None : Normal
Target Milestone: ---
Assignee: Hubert Mantel
QA Contact: E-mail List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-29 00:38 UTC by Phil Stopford
Modified: 2005-08-29 12:21 UTC (History)
2 users (show)

See Also:
Found By: Other
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Phil Stopford 2005-08-29 00:38:06 UTC
The kernel is still being provided in a suboptimal form for desktops. The
preemptible option is not enabled, for example, and aside from -default and
-smp, there is no -multimedia provision (for low latency kernels). Any
possibility of getting a more responsive kernel in the 10.0 release?
Comment 1 Hendrik Vogelsang 2005-08-29 10:20:13 UTC
How big was your measured performance improvement compared to our -default
kernel, which already contains many latency improvement over mainline?

Please provide some hard numbers using for instance lmbench or iobench
Comment 2 Takashi Iwai 2005-08-29 10:31:06 UTC
The preempt kernel reduces the throughput performance significantly although it
improves the realtime response.  It's a big trade-off.  Thus, unless we ship
serpate kernels, preempt can't be turned on --- it means, we would need to
double the number of kernels.  That's too much for a small benifit for "desktops".

For "normal desktop usage", I'd recommend rather to include Con's scheduler
patch than preempt.
Comment 3 Dr. Werner Fink 2005-08-29 10:46:08 UTC
Some applications and kernel driver get in trouble with preemptive.
Comment 4 Olaf Kirch 2005-08-29 12:21:50 UTC
Yes. We will not turn on CONFIG_PREEMPT. However, if you have specific numbers 
that show our kernel having latencies that prevent adequate multimedia 
playback, we're of course interested!