Re: [PATCH] Use extents for recording what swap is allocated.

[Nigel Cunningham]

Hi.

On Wed, 2006-10-25 at 10:11 +0200, Pavel Machek wrote:
> Hi!
> 
> > > > That's right. In using this, we're relying on the fact that the swap
> > > > allocator tries to act sensibly. I've only seen worse case performance
> > > > when a user had two swap devices with the same priority (striped), but
> > > > that was a bug. :)
> > > 
> > > Ok, but if the allocator somehow manages to stripe between two swap
> > > devices, what happens?
> > > 
> > > IIRC original code was something like .1% overhead (8bytes per 4K, or
> > > something?), bitmaps should be even better. If it is 1% in worst case,
> > > that's probably okay, but it would be bad if it had overhead bigger
> > > than 10times original code (worst case).
> > 
> > With the code I have in Suspend2 (which is what I'm working towards),
> > the value includes the swap_type, so there's no overlap. Assuming the
> > swap allocator does it's normal thing and swap allocated is contiguous,
> > you'll probably end up with two extents: one containing the swap
> > allocated on the first device, and the other containing the swap
> > allocated on the second device. So (with the current version), striping
> > would use 6 * sizeof(unsigned long) instead of 3 * sizeof(unsigned
> > long).
> 
> And now, can you do same computation assuming the swap allocator goes
> completely crazy, and free space is in 1-page chunks?

The worst case is 3 * sizeof(unsigned long) *
number_of_swap_extents_allocated bytes.

> In particular, how much swap space can we have before we run out of
> low memory? What is the overhead compared to bitmaps?

That depends on a lot of things: the size of swap space, the amount of
low memory available to begin with and so on.

I would simply say that 

1) the likelihood of the worst case is extremely low, particularly in an
age where swapspace is generally useless except for in suspending to
disk. If it was higher, your question would be much more poignant;

2) if the worst case happens, we should handle it properly, backing out,
freeing whatever we've allocated and returning control to the user, just
as we should if allocating a bitmap were to fail.

Regards,

Nigel

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/