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 20:05:50 +1000 [thread overview]
Message-ID: <1161770750.22729.117.camel@nigel.suspend2.net> (raw)
In-Reply-To: <20061025091022.GB7266@elf.ucw.cz>
Hi.
On Wed, 2006-10-25 at 11:10 +0200, Pavel Machek wrote:
> Hi!
>
> > > > > 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.
> > >
> > > Okay, so if we got 4GB of swap space, thats 1MB swap pages, worst case
> > > is you have one extent per page, on x86-64 that's 24MB. +kmalloc
> > > overhead, I assume?
> >
> > Sounds right.
>
> Ok, 24-50MB per 4GB of swap space is not _that_ bad...
Other way round: 12MB for x86, 24 for x86_64 is the worst case.
Actually, come to think of it, that would be for 8GB of swap space. The
worst case would require every page of swap to be alternately free and
allocated, so for 4GB you'd only have 2GB of swap allocated = 1/2 the
number of extents and half the memory requirements.
> > > And you do linear walks over those extents, leading to O(n^2)
> > > algorithm, no? That has bitten us before...
> >
> > We start from where we last added an extent on the chain by default.
>
> ...but linear search through 24MB _is_ going to hurt.
If we did one, yes it would. But this will be O(1) since we start at the
last value, and get_swap_page goes through the space sequentially.
> > You're not going to respond to the other bit of my reply? I was
> > beginning to think you were being more reasonable this time. Oh well.
>
> Rafael likes your code, and that's a big plus, but do you have to
> insult me?!
Pavel, I never seek to insult you and I'm sorry that you felt insulted
by my comment. In this case, I was expressing frustration at the fact
that you seemed to be (in my opinion anyway) being unreasonable in
completely ignoring and deleting my points about the likelihood of this
worse case scenario, and instead focusing on calculating the
requirements for such a worse case scenario, for a machine with at least
4 times the swapspace that most machines have today. I fully agree with
making things robust and considering worse case scenarios, and making
sure that patches are good and useful, but you seem to treat anything
that comes from me as if it's infected with the plague.
How about if we just call it quits and try to be nice to each other?
Regards,
Nigel
next prev parent reply other threads:[~2006-10-25 10:05 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
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 [this message]
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=1161770750.22729.117.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