From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: nigel@nigel.suspend2.net
Cc: Andrew Morton <akpm@linux-foundation.org>,
Pavel Machek <pavel@ucw.cz>, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFC][PATCH -mm] swsusp: Use rbtree for tracking allocated swap
Date: Sun, 8 Apr 2007 18:47:16 +0200 [thread overview]
Message-ID: <200704081847.16738.rjw@sisk.pl> (raw)
In-Reply-To: <1175989328.10725.59.camel@nigel.suspend2.net>
On Sunday, 8 April 2007 01:42, Nigel Cunningham wrote:
> Hi.
>
> On Sun, 2007-04-08 at 01:13 +0200, Rafael J. Wysocki wrote:
> > On Sunday, 8 April 2007 00:31, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Sat, 2007-04-07 at 15:06 -0700, Andrew Morton wrote:
> > > > On Sat, 7 Apr 2007 23:20:39 +0200 "Rafael J. Wysocki" <rjw@sisk.pl> wrote:
> > > >
> > > > > This should allow us to reduce the memory usage, practically always, and
> > > > > improve performance.
> > > >
> > > > And does it?
> >
> > Yes. There are theoretical corner cases in which it may be less efficient
> > than the current approach, but in the usual situation it is _much_ better.
> >
> > > It will. I've been using extents for ages, for the same reasons. I don't
> > > put them in an rb_tree because I view it as less than most efficient,
> >
> > Actually, I don't agree with that. In the normal situation (ie. one extent is
> > needed) there is no difference as far as the memory usage or performance
> > are concerned, but if there are more extents, the rbtree should be more
> > efficient.
>
> I don't think it's worth having a big discussion over, but let me give
> you the details, which you can then feel free to ignore :)
>
> The rb_node struct adds an unsigned long and two struct rb_node *
> pointers. My extents use one struct extent * pointer. The difference is
> thus 12/24 bytes per extent (32/64 bits) vs 20/40.
Well, you use open-coded lists. If you used list.h lists, the numbers
would be different. :-)
> In the normal situation, not worth worrying about, but I'm also using these for
> recording the sectors we write too, and thinking about swap files and
> multiple swap devices. Nearly double the memory use bites more as you
> get more extents.
>
> Insertion cost for rb_node includes keeping the tree balanced. For
> extents, I start with the location of the last insertion to minimise the
> cost, so insertion time is usually virtually zero (inc max of last
> extent or append a new one).
Isn't the appending one actually linear worst-case?
> If for some reason swap was allocated out of order, I might need to traverse
> the whole chain from the start.
Exactly.
> Normal usage in both cases is simply iterating through the list, so I
> guess the cost would be approximately the same.
>
> Deletion could would include rebalancing for the rb_nodes.
In swsusp the deletions are needed only if there's an error.
> Code cost is a gain for you - you're leveraging existing code, I'm
> adding a bit more. extent.c is 300 lines including code for serialising
> the chains in an image header and iterating through a group of chains
> (multiple swap devices support).
>
> rb_nodes seem to be the wrong solution to me because we generally don't
> care about searching. We care about minimising memory usage and
> maximising the speed of iteration, insertion and deletion. I believe
> I've managed to do that with a singly linked, sorted list.
The insertion also uses searching and in fact I don't really care for anything
else.
Greetings,
Rafael
next prev parent reply other threads:[~2007-04-08 16:43 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-07 21:20 [RFC][PATCH -mm] swsusp: Use rbtree for tracking allocated swap Rafael J. Wysocki
2007-04-07 22:06 ` Andrew Morton
2007-04-07 22:31 ` Nigel Cunningham
2007-04-07 23:13 ` Rafael J. Wysocki
2007-04-07 23:42 ` Nigel Cunningham
2007-04-08 16:47 ` Rafael J. Wysocki [this message]
2007-04-08 21:07 ` Nigel Cunningham
2007-04-09 13:03 ` Rafael J. Wysocki
2007-04-09 21:00 ` Nigel Cunningham
2007-04-08 12:56 ` Pavel Machek
2007-04-08 17:02 ` Rafael J. Wysocki
2007-04-09 12:39 ` Pavel Machek
2007-04-10 21:00 ` Rafael J. Wysocki
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=200704081847.16738.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nigel@nigel.suspend2.net \
--cc=pavel@ucw.cz \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.