|
Bugzilla – Full Text Bug Listing |
| Summary: | Kernel is not optimal for desktop systems | ||
|---|---|---|---|
| Product: | [openSUSE] SUSE LINUX 10.0 | Reporter: | Phil Stopford <phil> |
| Component: | Basesystem | Assignee: | Hubert Mantel <mantel> |
| Status: | RESOLVED WONTFIX | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P5 - None | CC: | meissner, tiwai |
| Version: | Beta 2 | ||
| Target Milestone: | --- | ||
| Hardware: | i686 | ||
| OS: | All | ||
| Whiteboard: | |||
| Found By: | Other | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
|
Description
Phil Stopford
2005-08-29 00:38:06 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 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. Some applications and kernel driver get in trouble with preemptive. 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! |