Re: a quest for a better scheduler

[Fabio Riccardi <fabio@chromium.com>]

Alan Cox wrote:

> > for the "normal case" performance see my other message.
>
> I did - and with a lot of interest

thanks! :)

> > I agree that a better threading model would surely help in a web server, but to
> > me this is not an excuse to live up with a broken scheduler.
>
> The problem has always been - alternative scheduler, crappier performance for
> 2 tasks running (which is most boxes). If your numbers are right then the
> HP patch is working as well for 1 or 2 tasks too

Please verify them if you have a couple of spare hours.

BTW: I measured similar results for the "scalability" patches on a 2.4.1 kernel, it
would be worth the effort to seriously compare them from an architectural point of
view, but I don't have the time right now...

> > Unless we want to maintain the position tha the only way to achieve good
> > performance is to embed server applications in the kernel, some minimal help
> > should be provided to goodwilling user applications :)
>
> Indeed. I'd love to see you beat tux entirely in userspace.  It proves the
> rest of the API for the kernel is right

Indeed, I'm using RT sigio/sigwait event scheduling, bare clone threads and
zero-copy io.

If only I had a really asynchronous sendfile, or a smarter madvise that wouldn't
require to map files :)

My server cannot execute dynamic stuff yet, it relies on Apache for that.

Running X15 and TUX in the same conditions (i.e. dynamic code in Apache) I get
exactly the same score in both cases.

I'm adding a TUX-like dynamic interface, I hope to get it to work by next week, then
I'll make a real confrontation.

Regards, ciao,

 - Fabio