Messages in this thread | | | Date | Sun, 2 May 2010 08:05:29 -0700 (PDT) | From | Dan Magenheimer <> | Subject | RE: Frontswap [PATCH 0/4] (was Transcendent Memory): overview |
| |
> > So there are two users of frontswap for which the synchronous > > interface makes sense. I believe there may be more in the > > future and you disagree but, as Jeremy said, "a general Linux > > principle is not to overdesign interfaces for hypothetical users, > > only for real needs." We have demonstrated there is a need > > with at least two users so the debate is only whether the > > number of users is two or more than two. > > > > Frontswap is a very non-invasive patch and is very cleanly > > layered so that if it is not in the presence of either of > > the intended "users", it can be turned off in many different > > ways with zero overhead (CONFIG'ed off) or extremely small overhead > > (frontswap_ops is never set; or frontswap_ops is set but the > > underlying hypervisor doesn't support it so frontswap_poolid > > never gets set). > > Yet there are less invasive solutions available, like 'add trim > operation to swap_ops'.
As Nitin pointed out much earlier in this thread:
"No: trim or discard is not useful"
I also think that trim does not do anything for the widely varying dynamically changing size that frontswap provides.
> So what needs to be said here is 'frontswap is XX times faster than > swap_ops based solution on workload YY'.
Are you asking me to demonstrate that swap-to-hypervisor-RAM is faster than swap-to-disk?
| |