lkml.org 
[lkml]   [2000]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: The INN/mmap bug
Date
Linus Torvalds wrote:
>
> On Mon, 18 Sep 2000, Alexander Viro wrote:
> > * we have several bh state components and the thing is a big,
> > fscking mess. If we look at the areas outside of the page lock we have:
>
> It's not a mess at all.
>
> I don't see why you call things "first stage" etc. It's perfectly
> straightforward. There are two bits that matter:
> - buffer uptodate
> - buffer mapped.
>
> And the state is very clear and unambiguous:
>
> Mapped, Uptodate: regular block
> !Mapped, Uptodate: hole of zeroes
> Mapped, !Uptodate: unread
> !Mapped, !Uptodate: "pending map"
>
> No "several states" at all.

The more I think about it the less clear and ambiguous I find it.
When you add the dirty bit into the pot you get:

Mapped, Uptodate, Dirty: not possible
!Mapped, Uptodate, Dirty: not possible
Mapped, !Uptodate, Dirty: pending write
!Mapped, !Uptodate, Dirty: pending map and write
Mapped, Uptodate, !Dirty: regular block
!Mapped, Uptodate, !Dirty: hole of zeroes
Mapped, !Uptodate, !Dirty: unread
!Mapped, !Uptodate, !Dirty: pending map

Those two 'not possible' states bother me, they show that the three
bits are not orthogonal. We can make arbitrary assignments of meaning
to them as you did with !Mapped, !Uptodate (pending map) but in that
case why not just enumerate all the states we need and lose the bit
assignments? I think the deep problem here is trying to look at this
as a bit-flipping problem instead of a state-transition problem.

I'm not saying that the current design can't be made to work. It can,
it's practically working now - it's just confusing as Al said, and
there are reasons for that. It gets more confusing when you add in
the less-than-simple relationship between buffers and pages and then
try to make sense of the combination of the two sets of states. The
motivation for making this less confusing is to be able to think about
optimization possibilities instead of just making it work.

--
Daniel
-
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/

\
 
 \ /
  Last update: 2005-03-22 12:39    [W:0.097 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site