I strongly agree with Andrea on that. Swap fault without page lock
was a step forward, reinstating it in the light of observed degradation
in one workload was right decision for that particular tail of release,
but it's a shame to have stayed that way.
> That is true, but it is ignoring the fact that there _are_ real technical
> differences between swap cache mappings and regular shared mappings.
>
> One major difference is the approach to the last user: a last use of a
> shared mapping still needs to write out dirty state, while the last use of
> a swap page is better off noticing that it should just optimize away the
> write, and we can just turn the page back into a dirty anonymous page.
Poor example: isn't last use of swap page just like last use of
shared mapping of an _unlinked_ file?
Offhand, I think most of the differences between swap and filesystem
just come from our wish not to waste any time on that filesystem:
we _expect_ the object will be unlinked before it needs to hit disk.
Plus, it's important that going to disk doesn't need more memory.
Perhaps those are just attributes of a particular filesystem.
Just as anon pages graduated to being put on LRU a few months ago,
maybe they could graduate to being hashed pages of tmpfs objects?
Probably yes, but without wasting time and memory - more doubtful.
Hugh
-
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/