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

>>> Henrik Nordstrom wrote
> > 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?
>
> All I know is that it does get triggered. There was some bugs in early
> implementations of request_queue2...

My instincts tell me it would get triggered most often on a machine with a
high request load and a fast disk - something where requests are being
serviced really quickly. Doesn't surprise me you can trigger it yourself on a
single CPU machine. I guess my concern comes mainly from the fact that I took
it as a load indicator (as that's how it looks like it's treated), when really
it's simply a context-switch-dodger - it carries no useful information about
the load the machine is under. I'd take the warnings out for use of it, in
truth. IMNSHO :)

> pthread_mutex_trylock is a "hit'n'miss" thing. But the important thing
> here is total queue latency, not how quickly the reques gets into the
> active queue. So it is sufficient to get the request into the queue
> quickly enough so it gets picked up by a I/O thread when all the
> requests in front of it has been processed. It does not matter if the
> request gets delayed in request_queue2 for 10ms if there already is 10ms
> of queued requests in front of it in request_queue. It still adds up to
> the same queue latency sum, only spent in different places.

I was wondering about this. The way it's coded atm favours getting requests
into the queue - that will happen as quickly as possible, if there's lots of
requests completing they doesn't get any help in clearing. If you locked
instead of trylocking, you'd force a context switch to clear reqs outgoing,
where appropriate. Given the context switch is bad, I'm happy this is a good
idea atm. I'm curious as to the effects on a multi-processor machine, where
the context switch may not be required(?).

Um. The issues with threading and reads/writes, I'll look more closely at
tomorrow when my head is clear - that code is not immediately transparent to
me, it still feels a bit "funny" - but I'm happier than I was ;) This issue
of request_queue2, I understand more fully now and am happy with, and will
carry it's implementation across into the new layout - thanks for the bundle
of informative emails ;) I think I better also write this stuff up somewhere
for future reference...

Oh, which reminds me: What should I do to get squidfs listed as a "hosted
here" project, instead of a "hosted elsewhere" project, and get a short
page or two up there explaining what it's about? I should start taking
responsibility for the sfs branch more properly.

KevinL
Received on Sat Mar 17 2001 - 07:31:02 MST