Re: Lockups with 2.4.14 and 2.4.16

[Andrea Arcangeli <andrea@suse.de>]

On Fri, Dec 14, 2001 at 10:57:56AM -0800, Andrew Morton wrote:
> Andrea Arcangeli wrote:
> > 
> > On Fri, Dec 14, 2001 at 12:53:00PM -0500, Chris Mason wrote:
> > > I'll try this, and also add kinoded so we can avoid using keventd.  I'm wary
> > 
> > using keventd for that doesn't look too bad to me. Just like we do with
> > the dirty inode flushing. keventd doesn't do anything 99.9% of the time,
> > so it sounds a bit wasteful to add yet another daemon that will remain
> > idle 99% of the time too... :)
> 
> Well heck, let's use ksoftirqd then :)

:)

ksoftirqd can run quite heavily sometime (it's needed for an efficient
NAPI for example) and it's not a general purpose kernel thread, and
all its work never blocks.

> keventd is used for real-time things - deferred interrupt
> actions.  It should be SCHED_FIFO.

The true fact is that keventd is _not_ SCHED_FIFO in 2.[245] and in turn
it _cannot_ be used for real time things.

So if keventd is currently used for real-time things, those real-time
things are malfunctioning right now, no matter of the dirty inode/quota
flushing.

furthmore the only point of keventd compared to a tasklet is that
keventd queued-tasks can _sleep_, and so all the users of keventd should
be used to block (if they cannot block they should use a taslket instead
that has a chance to be faster, per-cpu cache locality etc...).

> Actually, kupdated almost does what's needed already.  I
> suspect a wakeup_kupdate() would suffice.

Probably yes, however it would be nice to be able to push inode buffers
to disk while the buffers are getting flushed. So queueing the work to
keventd (or adding a kinoded) still sounds better to me :).

Andrea