bug-hurd
[Top][All Lists]
Advanced

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

Re: Dealing with thread storms


From: Sergio Lopez
Subject: Re: Dealing with thread storms
Date: Fri, 9 Apr 2010 21:33:04 +0200

El Fri, 9 Apr 2010 12:09:24 +0200
Thomas Schwinge <thomas@schwinge.name> escribió:

> Hello!
> 
> Sergio, great to see you're back!
> 

Thanks!
 
> 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.)
>

When Mach pages out the data of an object, it no longer cares about it.
It's the translator who must keep track of which pages are being paged
out, to prevent serving a m_o_data_request for a page without having
written it to the storage first.

Anyway, as I wrote in a previous mail, this change doesn't really fix
all the issues with lock_object/lock_completed mechanics, but at least
it should increase the stability of ext2fs until we have a proper
solution.
  
> You're not an enrolled student, are you?  Thinking about
> <http://www.gnu.org/software/hurd/community/gsoc.html> (application
> deadline today!).
> 

No, but I'm not interested either :)




reply via email to

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