it's the same trick that ramfs uses also, so it is the right way as far
as ramfs isn't broken too (and quite frankly these days ramfs is much
more important than ramdisk given our heavy use of logical caches).
> If you get a lot of stuff in ramdisks, things can get rather insteresting...
under heavy memory pressure possibly, that applies to ramfs also as said
above. Anyways this was a clean approch and the new vm make sure not to
get confused by writepage marking the page dirty again, the worst thing
that can happen is some cpu cycle wasted, _but_ we save cpu cycles in
not having special checks when ramfs isn't in use and the fact there are no
special cases also make the code cleaner.
Now, I'm fine to add special cases if this sort out to be too much cpu
wasted [check how much shrink_cache show up on the profiling to be sure]
(of course not just for ramdisk that isn't very important, but for ramfs
too which is much more critical to be very efficient).
Andrea
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/