public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Christian Brandt <brandtc@psi5.com>
To: Hugh Dickins <hughd@google.com>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	Ric Wheeler <ricwheeler@gmail.com>,
	linux-kernel@vger.kernel.org, Mike Snitzer <snitzer@redhat.com>
Subject: Re: swap storage alignment and stride size
Date: Fri, 17 Dec 2010 01:15:47 +0100	[thread overview]
Message-ID: <4D0AABB3.7050404@psi5.com> (raw)
In-Reply-To: <alpine.LSU.2.00.1012151627400.8734@tigran.mtv.corp.google.com>

Am 16.12.2010 01:42, schrieb Hugh Dickins:

> No, the 4k-aligned remains 4k-aligned, of course.  But if you aligned
> your swap partition on, say, a 1MB boundary, and are thinking of
> working in aligned 1MB blocks, then it may be awkward that there's
> always this special 4k at the start (it could be written back each
> time even though it hasn't changed, but it's still an odd case).

Hallo Hugh, I stayed a bit quit after my question to see what people
think. So I wasn't wrong from the start, neither kernel nor userland
tools care for anything beyond page size today. For today I'll be happy
enough with the status quo

Though I have a clear vision what I would like:

The kernel needs to be prepared to handle larger groups of pages.
In a perfect world it would favorite larger operations whicha are
already aligned to underlying architectures.
Eg, lets first write that very big 8192kiB chunk which is perfectly
aligned. But ignore the small pieces scattered around memory below the
chunk size until memory gets really low.
Small pieces don't eat up much memory any.
May it would even help to swap out only chunk-aligned parts even when
there are small pre- and post-data around the big chunk.

Also I would expect a userspace tool to setup a swap space with
alternate settings (e.g. offset to device start, chunk size, alignment)
- a nice new role for mkswap?

The chunk size shouldn't be any fixed value.
Often I have 64k, sometimes 256k, rarelly even 4096kiB.
And you never know what strange layouts are luring around the next
corner, maybe in 2015 we will all use SSD drives with a cell size of
12288kByte, already today several budget SSDs have pretty strange cell
sizes:
My cheapish Acer 24giB drive has 384kiB because it has connected three
8giB flash chips to the four channel controler with the fourth channel
being broken/disabled...

-- 
Christian Brandt

      parent reply	other threads:[~2010-12-17  0:15 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-12-08 17:03 swap storage alignment and stride size Christian Brandt
2010-12-08 19:56 ` Ric Wheeler
2010-12-14 20:00   ` Martin K. Petersen
2010-12-15  4:57     ` Hugh Dickins
2010-12-15 19:30       ` Martin K. Petersen
2010-12-16  0:42         ` Hugh Dickins
2010-12-16 23:46           ` Martin K. Petersen
2010-12-17  0:15           ` Christian Brandt [this message]

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=4D0AABB3.7050404@psi5.com \
    --to=brandtc@psi5.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.petersen@oracle.com \
    --cc=ricwheeler@gmail.com \
    --cc=snitzer@redhat.com \
    /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