On Thu, 15 Nov 2007, Linus Torvalds wrote:
>
> Unacceptable. We used to do exactly what your patch does, and it got fixed
> once. We're not introducing that fundamentally broken concept again.
Examples of non-broken solutions:
(a) always use lowmem sizes (what we do now)
(b) always use total mem sizes (sane but potentially dangerous: but the
VM pressure should work! It has serious bounce-buffer issues, though,
which is why I think it's crazy even if it's otherwise consistent)
(c) make all dirty counting be *purely* per-bdi, so that everybody can
disagree on what the limits are, but at least they also then use
different counters
So it's just the "different writers look at the same dirty counts but then
interpret it to mean totally different things" that I think is so
fundamentally bogus. I'm not claiming that what we do now is the only way
to do things, I just don't think your approach is tenable.
Btw, I actually suspect that while (a) is what we do now, for the specific
case that Bron has, we could have a /proc/sys/vm option to just enable
(b). So we don't have to have just one consistent model, we can allow odd
users (and Bron sounds like one - sorry Bron ;) to just force other, odd,
but consistent models.
I'd also like to point out that while the "bounce buffer" issue is not so
much a HIGHMEM issue on its own (it's really about the device DMA limits,
which are _independent_ of HIGHMEM, of course), the reason HIGHMEM is
special is that without HIGHMEM the bounce buffers generally work
perfectly fine.
The problem with HIGHMEM is that it causes various metadata (dentries,
inodes, page struct tables etc) to eat up memory "prime real estate" under
the same kind of conditions that also dirty a lot of memory. So the reason
we disallow HIGHMEM from dirty limits is only *partly* the per-device or
mapping DMA limits, and to a large degree the fact that non-highmem memory
is special in general, and it is usually the non-highmem areas that are
constrained - and need to be protected.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
