lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <4D0AABB3.7050404@psi5.com>
Date:	Fri, 17 Dec 2010 01:15:47 +0100
From:	Christian Brandt <brandtc@...5.com>
To:	Hugh Dickins <hughd@...gle.com>
CC:	"Martin K. Petersen" <martin.petersen@...cle.com>,
	Ric Wheeler <ricwheeler@...il.com>,
	linux-kernel@...r.kernel.org, Mike Snitzer <snitzer@...hat.com>
Subject: Re: swap storage alignment and stride size

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ