--
Yet another instance of my networked swap patches.
The patch-set consists of four parts:
- patches 1-2; the basic 'framework' for deadlock avoidance
- patches 3-9; implement swap over NFS
- patches 10-13; implement swap over NBD
- patches 14-20; implement swap over iSCSI
The iSCSI work depends on their .19 tree and does need some more work,
but does work in its current state.
As stated in previous posts, NFS and iSCSI survive service failures and
reconnect properly during heavy swapping.
Linus, when I mentioned swap over network to you in Ottawa, you said it was
a valid use case, that people actually do and want this. Can you agree with
the approach taken in these patches?
Peter
On Tue, 12 Sep 2006, Peter Zijlstra wrote:
>
> Linus, when I mentioned swap over network to you in Ottawa, you said it was
> a valid use case, that people actually do and want this. Can you agree with
> the approach taken in these patches?
Well, in all honesty, I don't think I really said "valid", but that I said
that some crazy people want to do it, and that we should try to allow them
their foibles.
So I'd be nervous to do any _guarantees_. I think that good VM policies
should make it be something that works in general (the dirty mapping
limits in particular), but I'd be a bit nervous about anybody taking it
_too_ seriously. Crazy people are still crazy, they just might be right
under certain reasonably-well-controlled circumstances.
Linus
On 9/12/06, Linus Torvalds <[email protected]> wrote:
>
>
> On Tue, 12 Sep 2006, Peter Zijlstra wrote:
> >
> > Linus, when I mentioned swap over network to you in Ottawa, you said it was
> > a valid use case, that people actually do and want this. Can you agree with
> > the approach taken in these patches?
>
> Well, in all honesty, I don't think I really said "valid", but that I said
> that some crazy people want to do it, and that we should try to allow them
> their foibles.
>
> So I'd be nervous to do any _guarantees_. I think that good VM policies
> should make it be something that works in general (the dirty mapping
> limits in particular), but I'd be a bit nervous about anybody taking it
> _too_ seriously. Crazy people are still crazy, they just might be right
> under certain reasonably-well-controlled circumstances.
(oops, forgot to cc: the list)
Personally, I'm a little unhappy with the added complexity here, I'm
not convinced that this extra feature is worth it. In particular,
adding to the address_space_operations, the block_device_operations,
and creating a new swap index/offset interface just for this seems
questionable. I feel like interface bloat should be reserved for
features that have widespread use and benefit.
Not that I'm opposed to this feature, just that I think this patch is
too invasive interface-wise.
NATE