Re: threaded fs'es was Re: native win32 aufs

>>> "Robert Collins" wrote
> Hmm you forgot the list :]

Doh.

> > Heh. I picked writes for a reason - for reads, there's an lseek in
> there
> > before each read (although I'm still not convinced from a read of that
> code
> > that it'd be thoroughly safe), but not for writes. Still, if I'm
> reading this
> > right, I would have expected to see more general strangeness for
> anyone using
> > aufs, so I'm presuming I'm missing _something_. The intervals in
> question are
> > very small tho, so it's possible we're just lucking out enough?
>
> See my comment on the state machine... Thats where my intuition says the
> safety margin is.

Ok. Is "one write per open fd" something we can rely on forever? Likewise
for reads? I agree, if that's the case, then it's safe - but I'm not
convinced that'll always be the case? In particular, do range requests affect
this at all, and will there be any aggregation of multiple clients into a
single open fd anytime? Do we want to try and code for this behaviour (gack,
what am I getting myself in for)?

> > Um. Actually, you'd just pthread_mutex_lock() the request_queue lock,
> that'd
> > return when the lock is unused (ie. when no other thread is removing a
> > request). Bearing in mind the "global" nature of the request_queue is
> going
> > away, that _should_ happen fast.
>
> It means that the control loop (which might have many requests to place
> on the queue from the result of the last select() will yield the cpu and
> possibly/porbably cause a context switch for no reason. I do think that
> the trylock is the more efficient approach, even if it is a little
> harder to code.

Hrm. Possibly... It's a lot of extra ops to dodge a context switch, tho -
especially given the only two places the lock is held besides that one are
trivially quick ops. When does this thing trigger in actual use?

pthread_mutex_trylock always feels a touch "hit'n'miss" to me - if it happens
we're dealing with another request atm, then no matter how quickly that
request is dealt with, we drop back to the failover thing. A sequence of bad
timing breaks, and it looks like we're overloaded, regardless of how quickly
requests are being dealt with. In fact, the quicker requests are dealt with,
the more likely this is to trigger, as we're spending more time proportionally
removing done requests from the queue...

KevinL
Received on Sat Mar 17 2001 - 04:54:16 MST