bug-hurd
[Top][All Lists]
Advanced

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

Re: Dealing with thread storms


From: Thomas Schwinge
Subject: Re: Dealing with thread storms
Date: Fri, 9 Apr 2010 12:09:24 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

Hello!

Sergio, great to see you're back!


On Wed, Apr 07, 2010 at 12:37:59PM +0200, Sergio Lopez wrote:
> To my knowledge, [...]

I can't comment on your assumptions, however:

> So I'm thinking about the following changes:
> 
>   - Implement a queue in libdiskfs to deal with m_o_data_return
>     requests and a static amount of consumers which will do the real
>     work. Each time the kernel sends us a m_o_data_return, we just add
>     the request to the queue and return the thread to the pool.

This means to make the number of workers (worker threads) no longer scale
according to the number of extant requests -- one fundamental problem
we're having not only in this context.  I don't know whether Mach will
cope with having its data return requests not being served immediatelly,
but I'm sure you know what you're doing here.  (And of course, we're
completely free to change Mach according to our needs.)

>   - Extend libpager interface to be able to write more than one page at
>     once, and progressively change the servers to make use this.
> 
>   - Whenever is possible, send more than one page a time. Right now,
>     m_o_lock_request tries to send up to 32 continuous pages, but vm
>     pageout process sends them one by one. OSF Mach implements
>     multipage discipline both for pageout and pagefault operations, so
>     it should be possible to do the same in GNU Mach (I've made some
>     work in this direction some time ago).

Yes, that sounds very usefull indeed -- this idea is not new, of course,
but nobody has been working on that, to my knowledge.

To sum up: I can only support you work on that!  :-)

You're not an enrolled student, are you?  Thinking about
<http://www.gnu.org/software/hurd/community/gsoc.html> (application
deadline today!).


Regards,
 Thomas

Attachment: signature.asc
Description: Digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]