[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: confused.



hendrik@topoi.pooq.com wrote:
On Thu, Sep 21, 2006 at 12:29:36PM +0200, Albert Dengg wrote:
On Wed, Sep 20, 2006 at 10:18:27PM +0100, David Mulcahy wrote:
On Wednesday 20 September 2006 15:04, Albert Dengg wrote:
On Tue, Sep 19, 2006 at 11:22:04PM +0100, David Mulcahy wrote:
Hello All

Just did a sarge -> etch upgrade.

Aptitude update , upgrade complained about libfam0 problems and stopped.

apt-get worked.  Although I have in the passed disabled inet using the
documentation on securing debian howto and this seemed to cause problems
with the upgrade netbase-inetd stopped with errors and caused ppp,
pppconfig, cupsys  to fail to configure.  Installing openbsd-inet cured
that problem.


I had upgraded because I wanted a preemptive kernel just to find it isnt
preemptive.  Is there likely to be a preemptive kernel available when
etch is ready.  I know I can compile it myself, I just feel there is a
need for it to be ready and available out of the box straight from
install.  Obviously I will compile one myself but for newcomers they may
look elsewhere, which would be a shame.

On my hardware a fully functional desktop is still a problem (eg music
and video) without a preemptive kernel so if debian is aiming at this
sector then a preempt kernel would be most welcome.
Well
i would feel that it may be good to have it as an _option_.
Yes that would be good. Am i right in thinking that once preempt is set then all the other refining can be set on the fly with /proc/sys/etc settings. Or can preempt be set with /proc?

as far as i know preemtive kernels do enhance the response time of the
system but on the other hand hurt performance for some server tasks....

and debian is to my knowlege more widly spread on the server side then
on the desktop side...

I guess I'm confused. I thought the debian kernel was preemptive, and has been as far as I can remember. Am I wrong? Or do I have a misunderstanding of what "preemptive" means in this context?

-- hendrik


What the posters are talking about is a new feature that allows the kernel to sort of stop everything to sort of handle some imminent situation such as sound processing etc. I found about this when using a few sound applications which required a sound mixer like daemon (I think) called jack (If you investigate jack and kernel preemption, you'll understand a little better what they're talking about).

As far as regular kernel process preemption (where the kernel is multitasking because it can preempt processes), that has never disappeared from the kernel.

I think the difference is that you may be thinking about the kernel process preemption and the posters above are talking about the "new" preemption that allows better processing for things such as sound using jack.

--
Sincerely
Jose Alburquerque



Reply to: