Re: Blocking read() policy?
From: Kasper Dupont (kasperd_at_daimi.au.dk)
Date: 07/24/05
- Next message: DazMe: "defunct processes after fork() + system()"
- Previous message: James Lehman: "Re: Linear framebuffer documentation"
- In reply to: Robert Redelmeier: "Re: Blocking read() policy?"
- Next in thread: Robert Redelmeier: "Re: Blocking read() policy?"
- Reply: Robert Redelmeier: "Re: Blocking read() policy?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Sun, 24 Jul 2005 11:40:54 +0200
Robert Redelmeier wrote:
>
> Kasper Dupont <kasperd@daimi.au.dk> wrote:
> > Preemption happens in entry.S and always did, those you
>
> entry.S has changed substantially, and the rescheduling check
> is very different. In 2.2.5 it is in the process' entry in
> the need_resched table. In 2.6.9 a call to the scheduler is
> in the direct return path, skipped only on different flags.
2.2.5 may call the scheduler on return to user mode,
2.6.9 may call the scheduler on return to user mode,
I don't see much of a difference.
>
> Linux' responsiveness has improved substantially.
Probably, but not so much of a difference that I
notice it when using the system.
> I believe
> quicker unblocking (at intr vs tick) has been one of the
> improvements.
That improvement happened before Linux 1.0 was
released.
-- Kasper Dupont -- der bruger for meget tid på usenet. Note to self: Don't try to allocate 256000 pages with GFP_KERNEL on x86.
- Next message: DazMe: "defunct processes after fork() + system()"
- Previous message: James Lehman: "Re: Linear framebuffer documentation"
- In reply to: Robert Redelmeier: "Re: Blocking read() policy?"
- Next in thread: Robert Redelmeier: "Re: Blocking read() policy?"
- Reply: Robert Redelmeier: "Re: Blocking read() policy?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|