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] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 28 Jun 2013 10:14:54 +0800
From:	Shaohua Li <shli@...nel.org>
To:	Rafael Aquini <aquini@...hat.com>
Cc:	linux-kernel@...r.kernel.org, linux-mm@...ck.org,
	akpm@...ux-foundation.org, hughd@...gle.com, kzak@...hat.com,
	jmoyer@...hat.com, kosaki.motohiro@...il.com, riel@...hat.com,
	lwoodman@...hat.com, mgorman@...e.de
Subject: Re: [PATCH 01/02] swap: discard while swapping only if
 SWAP_FLAG_DISCARD_PAGES

On Sun, May 26, 2013 at 01:31:55AM -0300, Rafael Aquini wrote:
> This patch introduces SWAP_FLAG_DISCARD_PAGES and SWAP_FLAG_DISCARD_ONCE
> new flags to allow more flexibe swap discard policies being flagged through
> swapon(8). The default behavior is to keep both single-time, or batched, area
> discards (SWAP_FLAG_DISCARD_ONCE) and fine-grained discards for page-clusters
> (SWAP_FLAG_DISCARD_PAGES) enabled, in order to keep consistentcy with older
> kernel behavior, as well as maintain compatibility with older swapon(8).
> However, through the new introduced flags the best suitable discard policy 
> can be selected accordingly to any given swap device constraint.

I'm sorry to response this thread so later. I thought if we just want to
discard the swap partition once at swapon, we really should do it in swapon
tool. The swapon tool can detect the swap device supports discard, any swap
partition is empty at swapon, and we have ioctl to do discard in userspace, so
we have no problem to do discard at the tool. If we don't want to do discard at
all, let the tool handles the option. Kernel is not the place to handle the
complexity.

Thanks,
Shaohua
--
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