linux-kernel - RE: swap on eMMC and other flash

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 05 Apr 2012 09:17:18 +0900
From:	정효진 <syr.jeong@...sung.com>
To:	'정효진' <syr.jeong@...sung.com>,
	'Arnd Bergmann' <arnd@...db.de>,
	'Hugh Dickins' <hughd@...gle.com>, cpgs@...sung.com
Cc:	linaro-kernel@...ts.linaro.org, 'Rik van Riel' <riel@...hat.com>,
	linux-mmc@...r.kernel.org,
	'Alex Lemberg' <alex.lemberg@...disk.com>,
	linux-kernel@...r.kernel.org,
	"'Luca Porzio (lporzio)'" <lporzio@...ron.com>, linux-mm@...ck.org,
	kernel-team@...roid.com, 'Yejin Moon' <yejin.moon@...sung.com>
Subject: RE: swap on eMMC and other flash

Dear Arnd

Hello, 

I'm not clearly understand the history of this e-mail communication because
I joined in the middle of mail thread.
Anyhow I would like to make comments for discard in swap area.
eMMC device point of view, there is no information of files which is used
in System S/W(Linux filesystem).
So...  In the eMMC, there is no way to know the address info of data which
was already erased.
If discard CMD send this information(address of erased files) to eMMC, old
data should be erased in the physical NAND level and get the free space
with minimizing internal merge.

I'm not sure that how Linux manage swap area.
If there are difference of information for invalid data between host and
eMMC device, discard to eMMC is good for performance of IO. It is as same
as general case of discard of user partition which is formatted with
filesystem.
As your e-mail mentioned, overwriting the logical address is the another
way to send info of invalid data address just for the overwrite area,
however it is not a best way for eMMC to manage physical NAND array. In
this case, eMMC have to trim physical NAND array, and do write operation at
the same time. It needs more latency.
If host send discard with invalid data address info in advance, eMMC can
find beat way to manage physical NAND page before host usage(write
operation).
I'm not sure it is the right comments of your concern.
If you need more info, please let me know

Best Regards
Hyojin

-----Original Message-----
From: Arnd Bergmann [mailto:arnd@...db.de]
Sent: Monday, April 02, 2012 11:55 PM
To: Hugh Dickins
Cc: linaro-kernel@...ts.linaro.org; Rik van Riel; linux-
mmc@...r.kernel.org; Alex Lemberg; linux-kernel@...r.kernel.org; Luca
Porzio (lporzio); linux-mm@...ck.org; Hyojin Jeong; kernel-
team@...roid.com; Yejin Moon
Subject: Re: swap on eMMC and other flash

On Monday 02 April 2012, Hugh Dickins wrote:
> On Mon, 2 Apr 2012, Arnd Bergmann wrote:
> > 
> > Another option would be batched discard as we do it for file systems:
> > occasionally stop writing to swap space and scanning for areas that 
> > have become available since the last discard, then send discard 
> > commands for those.
> 
> I'm not sure whether you've missed "swapon --discard", which switches 
> on discard_swap_cluster() just before we allocate from a new cluster; 
> or whether you're musing that it's no use to you because you want to 
> repurpose the swap cluster to match erase block: I'm mentioning it in 
> case you missed that it's already there (but few use it, since even 
> done at that scale it's often more trouble than it's worth).

I actually argued that discard_swap_cluster is exactly the right thing to
do, especially when clusters match erase blocks on the less capable devices
like SD cards.

Luca was arguing that on some hardware there is no point in ever submitting
a discard just before we start reusing space, because at that point it the
hardware already discards the old data by overwriting the logical addresses
with new blocks, while issuing a discard on all blocks as soon as they
become available would make a bigger difference. I would be interested in
hearing from Hyojin Jeong and Alex Lemberg what they think is the best time
to issue a discard, because they would know about other hardware than Luca.

	Arnd

--
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/