On Wed, 30 Aug 2000, Roman Zippel wrote:
> > Your repeated claims of VFS becoming more multi-threaded in ways
> > that are not transparent to fs drivers wrt locking are false.
>
> For example the usage of inode lock changed pretty much and was partly
> replaced with the page lock? I can still remember times, where all of the
> fs stuff happened under the BKL, for me that means only a _single_ thread
a) fs methods _are_ called under BKL.
b) BKL has nothing to single-processor races. Proof: definition of
lock_kernel() on non-SMP builds. You sleep - you lose BKL. schedule()
drops it (and restores when your process gets a timeslice again, but
whatever happens in the meanwhile - happens).
c) ->i_sem on pageout? When?
> of execution could be busy in the whole fs layer. IMHO that's not really a
> prime example of multi-threaded programming, if you have a different
> definition please let me now.
BKL matters only in the areas where you do not block. Moreover,
fs code is still under the BKL, so it's totally moot.
> > What? You've proposed locking on pageout. If _that_ isn't the fast path...
>
> No, I suggested a lock (not necessarily the inode lock) during allocation
> of indirect blocks (and defer truncation of them).
Which means pageout when you are dealing with sparse files. You
don't have them - fine, then you can take such lock right now.
> > > The major problem right now is that writepage() is supposed to be
> > > asynchronous especially for kswapd, but the fs might have to
> > > synchronized something _internal_. I think one problem here is that we
> > > still have a synchronous buffer API, what makes it very hard to
> > > implement a asynchronous interface. That's why I suggested an I/O
> >
> > Wrong. As the matter of fact, we could trivially get rid of _any_ use of
> > bread() and friends on ext2.
>
> Excuse my stupidity, but could you please outline me how?
Using kiovec, for one thing.
> > _One_ thread? For the whole fs? So you would pass the dirty pages from
> > kswapd to that guy. Fine. It attempts to acquire the inode semaphore (in
> > your proposal, as far as I could parse it). It blocks. kswapd keeps
> > pumping dirty pages into the queue of that thread. Wonderful...
>
> Sorry, but did you read my mail? The purpose of that thread is to sleep
> and to get waken up to continue the IO. Not very much changes, except that
> this thread can safely sleep, whereas kswapd can't.
> Excuse my ignorance, but who does currently stop kswapd to start lots of
> IO?
Filesystems, actually. The problem is not a burst of IO (it will not
happen - your thread is locked), but completely unnecessary interlock
between the output on different files.
> > b) doesn't help AFFS directory problems
>
> Why the hell do you come always with this, I _never_ mentioned it.
Let me put it that way:
It will not help with anything except a very specific problem with
sparse files.
You've mentioned handling of HFS. Guess what, there your suggestion gives
zero. Why? Because pageout on HFS never has a chance to allocate anything,
so no matter what/how you lock on allocation, kswapd doesn't enter the
picture. At all.
> > Talk is cheap. If you can show the patch that would simplify ext2,
> > I'm sure that Ted will be glad to see it. Same for maintainers of other
> > filesystems. The only requirement is that it should work. Excuse me, but
> > the longer I read your postings the more it looks like you have no idea of
> > the things you are talking about. I would be glad to be proven wrong on
> > that one too ;-/
>
> I'm very sorry to waste your precious time, but your fscking arrogance
> makes me sick. What's your problem? Shall I first worship you as our fs
> god who saved us from all races?
Huh???
> Sorry, but from time to time I prefer _first_ to think about a problem and
> I try to understand it. One way to do this is to post questions and/or
> suggestions to a mailing list (at least I thought so). If you have an
> other suggestion please enlighten me.
No problem with _that_.
How about we all calm down and do something more useful than this pissing
match? One thing that became really obvious is that current documentation
is either not enough or not read. Hell knows what to do about the latter,
but the former can be helped. We have several pieces of it - Richard's one
in the tree, Daniel's postings on fsdevel and several parts written by
various folks. This stuff needs to be merged (and corrected where needed).
I volunteer to do that - I've spent quite a while dealing with the code,
so I at least know what _is_ there. I would be really grateful if
* folks who have writeups would post URLs to them (or texts
themselves, if they are small enough). Preferably to fsdevel, but private
email will also go.
* people would comment after the result will be posted. Especially
about the missing / hard-to-understand pieces of text.
* somebody helped to turn the result into decent English text.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 31 2000 - 21:00:26 EST