Messages in this thread | | | From | Daniel Phillips <> | Subject | Re: The INN/mmap bug | Date | Tue, 19 Sep 2000 15:44:36 +0200 |
| |
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/
| |