> > 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? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href