All of lore.kernel.org
 help / color / mirror / Atom feed
From: 정효진 <syr.jeong@samsung.com>
To: "'Minchan Kim'" <minchan@kernel.org>,
	"'Alex Lemberg'" <Alex.Lemberg@sandisk.com>
Cc: "'Arnd Bergmann'" <arnd@arndb.de>,
	linaro-kernel@lists.linaro.org,
	"'Rik van Riel'" <riel@redhat.com>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	"'Luca Porzio (lporzio)'" <lporzio@micron.com>,
	linux-mm@kvack.org, kernel-team@android.com,
	"'Yejin Moon'" <yejin.moon@samsung.com>,
	"'Hugh Dickins'" <hughd@google.com>,
	"'Yaniv Iarovici'" <Yaniv.Iarovici@sandisk.com>,
	cpgs@samsung.com
Subject: RE: swap on eMMC and other flash
Date: Mon, 09 Apr 2012 16:37:53 +0900	[thread overview]
Message-ID: <006f01cd1623$ac4a2860$04de7920$%jeong@samsung.com> (raw)
In-Reply-To: <4F8245EA.6000600@kernel.org>

Hi Minchan

How are you doing?

Regarding time to issue Discard/Trim :
eMMC point of view, I believe that the immediate Discard/Trim CMD after deleting/freezing a SWAP cluster is always better for all of general eMMC implementation.

Regarding swap page size:
Actually, I can't guarantee the optimal size of different eMMC in the industry, because it depends on NAND page size an firmware implementation inside eMMC. In case of SAMSUNG eMMC, 8KB page size and 512KB block size(erase unit) is current implementation.
I think that the multiple of 8KB page size align with 512KB is good for SAMSUNG eMMC.
If swap system use 512KB page and issue Discard/Trim align with 512KB, eMMC make best performance as of today. However, large page size in swap partition may not best way in Linux system level.
I'm not sure that the best page size between Swap system and eMMC device.

Best Regards
Hyojin
-----Original Message-----
From: Minchan Kim [mailto:minchan@kernel.org] 
Sent: Monday, April 09, 2012 11:14 AM
To: Alex Lemberg
Cc: Arnd Bergmann; linaro-kernel@lists.linaro.org; Rik van Riel; linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Luca Porzio (lporzio); linux-mm@kvack.org; Hyojin Jeong; kernel-team@android.com; Yejin Moon; Hugh Dickins; Yaniv Iarovici
Subject: Re: swap on eMMC and other flash

2012-04-08 오후 10:50, Alex Lemberg 쓴 글:

> Hi Arnd,
> 
> Regarding time to issue discard/TRIM commands:
> It would be advised to issue the discard command immediately after deleting/freeing a SWAP cluster (i.e. as soon as it becomes available).


Is it still good with page size, not cluster size?

> 
> Regarding SWAP page size:
> Working with as large as SWAP pages as possible would be recommended (preferably 64KB). Also, writing in a sequential manner as much as possible while swapping large quantities of data is also advisable.
> 
> SWAP pages and corresponding transactions should be aligned to the SWAP page size (i.e. 64KB above), the alignment should correspond to the physical storage "LBA 0", i.e. to the first LBA of the storage device (and not to a logical/physical partition).
> 



I have a curiosity on above comment is valid on Samsung and other eMMC.
Hyojin, Could you answer?


> Thanks,
> Alex
> 
>> -----Original Message-----
>> From: Arnd Bergmann [mailto:arnd@arndb.de]
>> Sent: Monday, April 02, 2012 5:55 PM
>> To: Hugh Dickins
>> Cc: linaro-kernel@lists.linaro.org; Rik van Riel; linux- 
>> mmc@vger.kernel.org; Alex Lemberg; linux-kernel@vger.kernel.org; Luca 
>> Porzio (lporzio); linux-mm@kvack.org; Hyojin Jeong; kernel- 
>> team@android.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
> 
> PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in the body 
> to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign 
> http://stopthemeter.ca/ Don't email: <a href=ilto:"dont@kvack.org"> 
> email@kvack.org </a>
> 



--
Kind regards,
Minchan Kim


WARNING: multiple messages have this Message-ID (diff)
From: 정효진 <syr.jeong@samsung.com>
To: 'Minchan Kim' <minchan@kernel.org>,
	'Alex Lemberg' <Alex.Lemberg@sandisk.com>
Cc: 'Arnd Bergmann' <arnd@arndb.de>,
	linaro-kernel@lists.linaro.org, 'Rik van Riel' <riel@redhat.com>,
	linux-mmc@vger.kernel.org, linux-kernel@vger.kernel.org,
	"'Luca Porzio (lporzio)'" <lporzio@micron.com>,
	linux-mm@kvack.org, kernel-team@android.com,
	'Yejin Moon' <yejin.moon@samsung.com>,
	'Hugh Dickins' <hughd@google.com>,
	'Yaniv Iarovici' <Yaniv.Iarovici@sandisk.com>,
	cpgs@samsung.com
Subject: RE: swap on eMMC and other flash
Date: Mon, 09 Apr 2012 16:37:53 +0900	[thread overview]
Message-ID: <006f01cd1623$ac4a2860$04de7920$%jeong@samsung.com> (raw)
In-Reply-To: <4F8245EA.6000600@kernel.org>

Hi Minchan

How are you doing?

Regarding time to issue Discard/Trim :
eMMC point of view, I believe that the immediate Discard/Trim CMD after deleting/freezing a SWAP cluster is always better for all of general eMMC implementation.

Regarding swap page size:
Actually, I can't guarantee the optimal size of different eMMC in the industry, because it depends on NAND page size an firmware implementation inside eMMC. In case of SAMSUNG eMMC, 8KB page size and 512KB block size(erase unit) is current implementation.
I think that the multiple of 8KB page size align with 512KB is good for SAMSUNG eMMC.
If swap system use 512KB page and issue Discard/Trim align with 512KB, eMMC make best performance as of today. However, large page size in swap partition may not best way in Linux system level.
I'm not sure that the best page size between Swap system and eMMC device.

Best Regards
Hyojin
-----Original Message-----
From: Minchan Kim [mailto:minchan@kernel.org] 
Sent: Monday, April 09, 2012 11:14 AM
To: Alex Lemberg
Cc: Arnd Bergmann; linaro-kernel@lists.linaro.org; Rik van Riel; linux-mmc@vger.kernel.org; linux-kernel@vger.kernel.org; Luca Porzio (lporzio); linux-mm@kvack.org; Hyojin Jeong; kernel-team@android.com; Yejin Moon; Hugh Dickins; Yaniv Iarovici
Subject: Re: swap on eMMC and other flash

2012-04-08 오후 10:50, Alex Lemberg 쓴 글:

> Hi Arnd,
> 
> Regarding time to issue discard/TRIM commands:
> It would be advised to issue the discard command immediately after deleting/freeing a SWAP cluster (i.e. as soon as it becomes available).


Is it still good with page size, not cluster size?

> 
> Regarding SWAP page size:
> Working with as large as SWAP pages as possible would be recommended (preferably 64KB). Also, writing in a sequential manner as much as possible while swapping large quantities of data is also advisable.
> 
> SWAP pages and corresponding transactions should be aligned to the SWAP page size (i.e. 64KB above), the alignment should correspond to the physical storage "LBA 0", i.e. to the first LBA of the storage device (and not to a logical/physical partition).
> 



I have a curiosity on above comment is valid on Samsung and other eMMC.
Hyojin, Could you answer?


> Thanks,
> Alex
> 
>> -----Original Message-----
>> From: Arnd Bergmann [mailto:arnd@arndb.de]
>> Sent: Monday, April 02, 2012 5:55 PM
>> To: Hugh Dickins
>> Cc: linaro-kernel@lists.linaro.org; Rik van Riel; linux- 
>> mmc@vger.kernel.org; Alex Lemberg; linux-kernel@vger.kernel.org; Luca 
>> Porzio (lporzio); linux-mm@kvack.org; Hyojin Jeong; kernel- 
>> team@android.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
> 
> PLEASE NOTE: The information contained in this electronic mail message is intended only for the use of the designated recipient(s) named above. If the reader of this message is not the intended recipient, you are hereby notified that you have received this message in error and that any review, dissemination, distribution, or copying of this message is strictly prohibited. If you have received this communication in error, please notify the sender by telephone or e-mail (as shown above) immediately and destroy any and all copies of this message in your possession (whether hard copies or electronically stored copies).
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in the body 
> to majordomo@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Fight unfair telecom internet charges in Canada: sign 
> http://stopthemeter.ca/ Don't email: <a href=ilto:"dont@kvack.org"> 
> email@kvack.org </a>
> 



--
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

  reply	other threads:[~2012-04-09  7:45 UTC|newest]

Thread overview: 89+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-30 17:44 swap on eMMC and other flash Arnd Bergmann
2012-03-30 17:44 ` Arnd Bergmann
2012-03-30 18:50 ` Arnd Bergmann
2012-03-30 18:50   ` Arnd Bergmann
2012-03-30 22:08   ` Zach Pfeffer
2012-03-30 22:08     ` Zach Pfeffer
2012-03-31  9:24     ` Arnd Bergmann
2012-03-31  9:24       ` Arnd Bergmann
2012-04-03 18:17       ` Zach Pfeffer
2012-04-03 18:17         ` Zach Pfeffer
2012-03-31 20:29   ` Hugh Dickins
2012-03-31 20:29     ` Hugh Dickins
2012-03-31 20:29     ` Hugh Dickins
2012-04-02 11:45     ` Arnd Bergmann
2012-04-02 11:45       ` Arnd Bergmann
2012-04-02 14:41       ` Hugh Dickins
2012-04-02 14:41         ` Hugh Dickins
2012-04-02 14:55         ` Arnd Bergmann
2012-04-02 14:55           ` Arnd Bergmann
2012-04-05  0:17           ` 정효진
2012-04-05  0:17             ` 정효진
2012-04-09 12:50             ` Arnd Bergmann
2012-04-09 12:50               ` Arnd Bergmann
2012-04-08 13:50           ` Alex Lemberg
2012-04-08 13:50             ` Alex Lemberg
2012-04-09  2:14             ` Minchan Kim
2012-04-09  2:14               ` Minchan Kim
2012-04-09  7:37               ` 정효진 [this message]
2012-04-09  7:37                 ` 정효진
2012-04-09  8:11                 ` Minchan Kim
2012-04-09  8:11                   ` Minchan Kim
2012-04-09  8:11                   ` Minchan Kim
2012-04-09 13:00                   ` Arnd Bergmann
2012-04-09 13:00                     ` Arnd Bergmann
2012-04-10  1:10                     ` Minchan Kim
2012-04-10  1:10                       ` Minchan Kim
2012-04-10  8:40                       ` Arnd Bergmann
2012-04-10  8:40                         ` Arnd Bergmann
2012-04-12  8:32                         ` Luca Porzio (lporzio)
2012-04-12  8:32                           ` Luca Porzio (lporzio)
2012-04-09 12:54                 ` Arnd Bergmann
2012-04-09 12:54                   ` Arnd Bergmann
2012-04-02 12:52     ` Luca Porzio (lporzio)
2012-04-02 12:52       ` Luca Porzio (lporzio)
2012-04-02 14:58       ` Hugh Dickins
2012-04-02 14:58         ` Hugh Dickins
2012-04-02 16:51         ` Rik van Riel
2012-04-02 16:51           ` Rik van Riel
2012-04-04 12:21   ` Adrian Hunter
2012-04-04 12:21     ` Adrian Hunter
2012-04-04 12:47     ` Arnd Bergmann
2012-04-04 12:47       ` Arnd Bergmann
2012-04-11 10:28       ` Adrian Hunter
2012-04-11 10:28         ` Adrian Hunter
2012-07-16 13:29         ` Pavel Machek
2012-07-16 13:29           ` Pavel Machek
2012-04-06  7:15 ` Minchan Kim
2012-04-06 16:16   ` Arnd Bergmann
2012-04-06 16:16     ` Arnd Bergmann
2012-04-09  2:06     ` Minchan Kim
2012-04-09  2:06       ` Minchan Kim
2012-04-09  2:06       ` Minchan Kim
2012-04-09 12:35       ` Arnd Bergmann
2012-04-09 12:35         ` Arnd Bergmann
2012-04-09 12:35         ` Arnd Bergmann
2012-04-10  0:57         ` Minchan Kim
2012-04-10  0:57           ` Minchan Kim
2012-04-10  0:57           ` Minchan Kim
2012-04-10  8:32           ` Arnd Bergmann
2012-04-10  8:32             ` Arnd Bergmann
2012-04-10  8:32             ` Arnd Bergmann
2012-04-11  9:54             ` Minchan Kim
2012-04-11  9:54               ` Minchan Kim
2012-04-11 15:57               ` Arnd Bergmann
2012-04-11 15:57                 ` Arnd Bergmann
2012-04-12  2:36                 ` Minchan Kim
2012-04-12  2:36                   ` Minchan Kim
2012-04-16 18:22                 ` Stephan Uphoff
2012-04-16 18:22                   ` Stephan Uphoff
2012-04-16 18:59                   ` Arnd Bergmann
2012-04-16 18:59                     ` Arnd Bergmann
2012-04-16 21:12                     ` Stephan Uphoff
2012-04-16 21:12                       ` Stephan Uphoff
2012-04-17  2:18                       ` Minchan Kim
2012-04-17  2:18                         ` Minchan Kim
2012-04-17  2:05                     ` Minchan Kim
2012-04-17  2:05                       ` Minchan Kim
2012-04-27  7:34                   ` Luca Porzio (lporzio)
2012-04-27  7:34                     ` Luca Porzio (lporzio)

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='006f01cd1623$ac4a2860$04de7920$%jeong@samsung.com' \
    --to=syr.jeong@samsung.com \
    --cc=Alex.Lemberg@sandisk.com \
    --cc=Yaniv.Iarovici@sandisk.com \
    --cc=arnd@arndb.de \
    --cc=cpgs@samsung.com \
    --cc=hughd@google.com \
    --cc=kernel-team@android.com \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linux-mmc@vger.kernel.org \
    --cc=lporzio@micron.com \
    --cc=minchan@kernel.org \
    --cc=riel@redhat.com \
    --cc=yejin.moon@samsung.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.