From: Nigel Cunningham <ncunningham@linuxmail.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: "Rafael J. Wysocki" <rjw@sisk.pl>, Andrew Morton <akpm@osdl.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Use extents for recording what swap is allocated.
Date: Wed, 25 Oct 2006 08:15:53 +1000 [thread overview]
Message-ID: <1161728153.22729.22.camel@nigel.suspend2.net> (raw)
In-Reply-To: <20061024213402.GC5662@elf.ucw.cz>
Hi.
On Tue, 2006-10-24 at 23:34 +0200, Pavel Machek wrote:
> Hi!
>
> > > Switch from bitmaps to using extents to record what swap is allocated;
> > > they make more efficient use of memory, particularly where the allocated
> > > storage is small and the swap space is large.
> >
> > As I said before, I like the overall idea, but I have a bunch of
> > comments.
>
> Okay, if Rafael likes it... lets take a look.
>
> First... what is the _worst case_ overhead? AFAICT extents are very
> good at the best case, but tend to suck for the worst case...?
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. :)
> > > +#include <linux/suspend.h>
> > > +#include "extent.h"
> > > +
> > > +/* suspend_get_extent
> > > + *
> > > + * Returns a free extent. May fail, returning NULL instead.
> > > + */
>
> Your comments are nice, and quite close to linuxdoc... Can we make
> them proper linuxdoc?
Ok.
> > > +/* suspend_put_extent_chain.
> > > + *
> > > + * Frees a whole chain of extents.
> > > + */
> > > +void suspend_put_extent_chain(struct extent_chain *chain)
> >
> > I'd call it suspend_free_all_extents().
>
> This is actually important. As it does undocditional free(), it may
> not be called "put".
Ok.
> > > +#ifndef EXTENT_H
> > > +#define EXTENT_H
> > > +
> > > +struct extent {
> > > + unsigned long minimum, maximum;
> >
> > Well, I'd use shorter names, but whatever.
>
> Actually, minimum and
> maximum look too similar. start/end are really better names.
Ok.
Thanks!
Nigel
next prev parent reply other threads:[~2006-10-24 22:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-23 4:14 [PATCH] Use extents for recording what swap is allocated Nigel Cunningham
2006-10-23 15:32 ` Pavel Machek
2006-10-23 23:04 ` Nigel Cunningham
2006-10-24 8:43 ` Rafael J. Wysocki
2006-10-24 20:08 ` Rafael J. Wysocki
2006-10-24 21:34 ` Pavel Machek
2006-10-24 21:58 ` Rafael J. Wysocki
2006-10-24 22:15 ` Nigel Cunningham [this message]
2006-10-24 22:19 ` Pavel Machek
2006-10-24 22:30 ` Nigel Cunningham
2006-10-25 8:11 ` Pavel Machek
2006-10-25 8:28 ` Nigel Cunningham
2006-10-25 8:42 ` Pavel Machek
2006-10-25 9:01 ` Nigel Cunningham
2006-10-25 9:10 ` Pavel Machek
2006-10-25 10:05 ` Nigel Cunningham
2006-10-25 12:46 ` Rafael J. Wysocki
2006-10-27 11:37 ` Pavel Machek
2006-10-24 22:13 ` Nigel Cunningham
2006-10-24 22:45 ` Rafael J. Wysocki
2006-10-24 23:05 ` Nigel Cunningham
2006-10-31 11:39 ` Nigel Cunningham
2006-10-24 20:42 ` Christoph Hellwig
2006-10-24 20:58 ` Rafael J. Wysocki
2006-10-24 22:06 ` Nigel Cunningham
2006-10-24 22:47 ` Christoph Hellwig
2006-10-24 23:03 ` Nigel Cunningham
2006-10-25 9:17 ` Jens Axboe
2006-10-25 10:07 ` Nigel Cunningham
2006-10-25 10:20 ` Jens Axboe
2006-10-31 11:38 ` Nigel Cunningham
2006-11-01 12:36 ` Pavel Machek
2006-11-01 21:19 ` Nigel Cunningham
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1161728153.22729.22.camel@nigel.suspend2.net \
--to=ncunningham@linuxmail.org \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@ucw.cz \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox