Maya Erez | 2 Jul 14:15 2012

[PATCH v4 0/1] mmc: block: Add write packing control

Our experiments showed that the write packing causes degradation of the read
throughput, in parallel read and write operations.
Since the read latency is critical for user experience we added a write packing control
mechanism that disables the write packing in case of read requests.
This will ensure that read requests latency is not increased due to long write packed commands.

The trigger for enabling the write packing is managing to pack several write requests.
The number of potential packed requests that will trigger the packing can be configured via sysfs.
The trigger for disabling the write packing is a fetch of a read request.

this patch is dependant in the following patches:
  [PATCH v8 1/3] mmc: core: Add packed command feature of eMMC4.5
  [PATCH v8 2/3] mmc: core: Support packed write command for eMMC4.5 device

Changes in v4:
    - Move MMC specific attributes to mmc sub-directory

Changes in v3:
    - Fix the settings of num_of_potential_packed_wr_reqs

Changes in v2:
    - Move the attribute for setting the packing enabling trigger to the block device
    - Add documentation of the new attribute

Maya Erez (2):
  mmc: card: Move MMC specific attributes to mmc sub-directory
  mmc: block: Add write packing control

 Documentation/mmc/mmc-dev-attrs.txt |   17 ++++
 drivers/mmc/card/block.c            |  176 +++++++++++++++++++++++++++++++++--
(Continue reading)

Maya Erez | 2 Jul 14:15 2012

[PATCH v4 1/2] mmc: card: Move MMC specific attributes to mmc sub-directory

Separate MMC specific attributes from general block device
attributes and move them from the /sys/block/≤BLOCK_DEV> directory
to /sys/block/≤BLOCK_DEV>/mmc directory

Signed-off-by: Maya Erez <merez <at> codeaurora.org>

diff --git a/drivers/mmc/card/block.c b/drivers/mmc/card/block.c
index c965f2b..c23034d 100644
--- a/drivers/mmc/card/block.c
+++ b/drivers/mmc/card/block.c
 <at>  <at>  -114,6 +114,9  <at>  <at>  struct mmc_blk_data {
 	struct device_attribute force_ro;
 	struct device_attribute power_ro_lock;
 	int	area_type;
+
+	struct kobject kobj;
+	struct kobj_type kobj_type;
 };

 static DEFINE_MUTEX(open_lock);
 <at>  <at>  -185,6 +188,51  <at>  <at>  static void mmc_blk_put(struct mmc_blk_data *md)
 	mutex_unlock(&open_lock);
 }

+static ssize_t mmc_blk_attr_show(struct kobject *kobj, struct attribute *attr,
+			    char *buf)
+{
+	struct device_attribute *dev_attr;
+	struct mmc_blk_data *md;
+	ssize_t ret;
(Continue reading)

Maya Erez | 2 Jul 14:15 2012

[PATCH v4 2/2] mmc: block: Add write packing control

The write packing control will ensure that read requests latency is
not increased due to long write packed commands.

The trigger for enabling the write packing is managing to pack several
write requests. The number of potential packed requests that will trigger
the packing can be configured via sysfs by writing the required value to:
/sys/block/≤block_dev_name>/num_wr_reqs_to_start_packing.
The trigger for disabling the write packing is fetching a read request.

Signed-off-by: Maya Erez <merez <at> codeaurora.org>

diff --git a/Documentation/mmc/mmc-dev-attrs.txt b/Documentation/mmc/mmc-dev-attrs.txt
index 22ae844..f4a48a8 100644
--- a/Documentation/mmc/mmc-dev-attrs.txt
+++ b/Documentation/mmc/mmc-dev-attrs.txt
 <at>  <at>  -8,6 +8,23  <at>  <at>  The following attributes are read/write.

 	force_ro		Enforce read-only access even if write protect switch is off.

+	num_wr_reqs_to_start_packing 	This attribute is used to determine
+	the trigger for activating the write packing, in case the write
+	packing control feature is enabled.
+
+	When the MMC manages to reach a point where num_wr_reqs_to_start_packing
+	write requests could be packed, it enables the write packing feature.
+	This allows us to start the write packing only when it is beneficial
+	and has minimum affect on the read latency.
+
+	The number of potential packed requests that will trigger the packing
+	can be configured via sysfs by writing the required value to:
(Continue reading)

Rabin Vincent | 5 Jul 11:28 2012
Picon

Re: Bad use of highmem with buffer_migrate_page?

On Sat, May 12, 2012 at 3:21 AM, Laura Abbott <lauraa <at> codeaurora.org> wrote:
> On 5/11/2012 1:30 AM, Marek Szyprowski wrote:
>> On Thursday, May 10, 2012 10:08 PM Laura Abbott wrote:
>>> I did a backport of the Contiguous Memory Allocator to a 3.0.8 tree. I
>>> wrote fairly simple test case that, in 1MB chunks, allocs up to 40MB
>>> from a reserved area, maps, writes, unmaps and then frees in an infinite
>>> loop. When running this with another program in parallel to put some
>>> stress on the filesystem, I hit data aborts in the filesystem/journal
>>> layer, although not always the same backtrace. As an example:
>>>
>>> [<c02907a4>] (__ext4_check_dir_entry+0x20/0x184) from [<c029e1a8>]
>>> (add_dirent_to_buf+0x70/0x2ac)
>>> [<c029e1a8>] (add_dirent_to_buf+0x70/0x2ac) from [<c029f3f0>]
>>> (ext4_add_entry+0xd8/0x4bc)
>>> [<c029f3f0>] (ext4_add_entry+0xd8/0x4bc) from [<c029fe90>]
>>> (ext4_add_nondir+0x14/0x64)
>>> [<c029fe90>] (ext4_add_nondir+0x14/0x64) from [<c02a04c4>]
>>> (ext4_create+0xd8/0x120)
>>> [<c02a04c4>] (ext4_create+0xd8/0x120) from [<c022e134>]
>>> (vfs_create+0x74/0xa4)
>>> [<c022e134>] (vfs_create+0x74/0xa4) from [<c022ed3c>]
>>> (do_last+0x588/0x8d4)
>>> [<c022ed3c>] (do_last+0x588/0x8d4) from [<c022fe64>]
>>> (path_openat+0xc4/0x394)
>>> [<c022fe64>] (path_openat+0xc4/0x394) from [<c0230214>]
>>> (do_filp_open+0x30/0x7c)
>>> [<c0230214>] (do_filp_open+0x30/0x7c) from [<c0220cb4>]
>>> (do_sys_open+0xd8/0x174)
>>> [<c0220cb4>] (do_sys_open+0xd8/0x174) from [<c0105ea0>]
>>> (ret_fast_syscall+0x0/0x30)
(Continue reading)

Marek Szyprowski | 5 Jul 12:05 2012

RE: Bad use of highmem with buffer_migrate_page?

Hello,

On Thursday, July 05, 2012 11:28 AM Rabin Vincent wrote:

> On Sat, May 12, 2012 at 3:21 AM, Laura Abbott <lauraa <at> codeaurora.org> wrote:
> > On 5/11/2012 1:30 AM, Marek Szyprowski wrote:
> >> On Thursday, May 10, 2012 10:08 PM Laura Abbott wrote:
> >>> I did a backport of the Contiguous Memory Allocator to a 3.0.8 tree. I
> >>> wrote fairly simple test case that, in 1MB chunks, allocs up to 40MB
> >>> from a reserved area, maps, writes, unmaps and then frees in an infinite
> >>> loop. When running this with another program in parallel to put some
> >>> stress on the filesystem, I hit data aborts in the filesystem/journal
> >>> layer, although not always the same backtrace. As an example:
> >>>
> >>> [<c02907a4>] (__ext4_check_dir_entry+0x20/0x184) from [<c029e1a8>]
> >>> (add_dirent_to_buf+0x70/0x2ac)
> >>> [<c029e1a8>] (add_dirent_to_buf+0x70/0x2ac) from [<c029f3f0>]
> >>> (ext4_add_entry+0xd8/0x4bc)
> >>> [<c029f3f0>] (ext4_add_entry+0xd8/0x4bc) from [<c029fe90>]
> >>> (ext4_add_nondir+0x14/0x64)
> >>> [<c029fe90>] (ext4_add_nondir+0x14/0x64) from [<c02a04c4>]
> >>> (ext4_create+0xd8/0x120)
> >>> [<c02a04c4>] (ext4_create+0xd8/0x120) from [<c022e134>]
> >>> (vfs_create+0x74/0xa4)
> >>> [<c022e134>] (vfs_create+0x74/0xa4) from [<c022ed3c>]
> >>> (do_last+0x588/0x8d4)
> >>> [<c022ed3c>] (do_last+0x588/0x8d4) from [<c022fe64>]
> >>> (path_openat+0xc4/0x394)
> >>> [<c022fe64>] (path_openat+0xc4/0x394) from [<c0230214>]
> >>> (do_filp_open+0x30/0x7c)
(Continue reading)

Rabin Vincent | 5 Jul 12:45 2012
Picon

Re: Bad use of highmem with buffer_migrate_page?

On Thu, Jul 05, 2012 at 12:05:45PM +0200, Marek Szyprowski wrote:
> On Thursday, July 05, 2012 11:28 AM Rabin Vincent wrote:
> > The problem is still present on latest mainline.  The filesystem layer
> > expects that the pages in the block device's mapping are not in highmem
> > (the mapping's gfp mask is set in bdget()), but CMA replaces lowmem
> > pages with highmem pages leading to the crashes.
> > 
> > The above fix should work, but perhaps the following is preferable since
> > it should allow moving highmem pages to other highmem pages?
> 
> > diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> > index 4403009..4a4f921 100644
> > --- a/mm/page_alloc.c
> > +++ b/mm/page_alloc.c
> >  <at>  <at>  -5635,7 +5635,12  <at>  <at>  static struct page *
> >  __alloc_contig_migrate_alloc(struct page *page, unsigned long private,
> >  			     int **resultp)
> >  {
> > -	return alloc_page(GFP_HIGHUSER_MOVABLE);
> > +	gfp_t gfp_mask = GFP_USER | __GFP_MOVABLE;
> > +
> > +	if (PageHighMem(page))
> > +		gfp_mask |= __GFP_HIGHMEM;
> > +
> > +	return alloc_page(gfp_mask);
> >  }
> > 
> >  /* [start, end) must belong to a single zone. */
> 
> 
(Continue reading)

Cong Wang | 5 Jul 15:56 2012
Picon

Re: Bad use of highmem with buffer_migrate_page?

On Thu, 05 Jul 2012 at 10:45 GMT, Rabin Vincent <rabin <at> rab.in> wrote:
> 8<----
> From 8a94126eb3aa2824866405fb78bb0b8316f8fd00 Mon Sep 17 00:00:00 2001
> From: Rabin Vincent <rabin <at> rab.in>
> Date: Thu, 5 Jul 2012 15:52:23 +0530
> Subject: [PATCH] mm: cma: don't replace lowmem pages with highmem
>
> The filesystem layer expects pages in the block device's mapping to not
> be in highmem (the mapping's gfp mask is set in bdget()), but CMA can
> currently replace lowmem pages with highmem pages, leading to crashes in
> filesystem code such as the one below:
>
...
> Fix this by replacing only highmem pages with highmem.
>

Looks good to me too,

    Reviewed-by: WANG Cong <xiyou.wangcong <at> gmail.com>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo <at> kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont <at> kvack.org"> email <at> kvack.org </a>

Michał Nazarewicz | 5 Jul 21:21 2012

Re: Bad use of highmem with buffer_migrate_page?

2012/7/5 Rabin Vincent <rabin <at> rab.in>:
> From 8a94126eb3aa2824866405fb78bb0b8316f8fd00 Mon Sep 17 00:00:00 2001
> From: Rabin Vincent <rabin <at> rab.in>
> Date: Thu, 5 Jul 2012 15:52:23 +0530
> Subject: [PATCH] mm: cma: don't replace lowmem pages with highmem
>
> The filesystem layer expects pages in the block device's mapping to not
> be in highmem (the mapping's gfp mask is set in bdget()), but CMA can
> currently replace lowmem pages with highmem pages, leading to crashes in
> filesystem code such as the one below:
>
>   Unable to handle kernel NULL pointer dereference at virtual address 00000400
>   pgd = c0c98000
>   [00000400] *pgd=00c91831, *pte=00000000, *ppte=00000000
>   Internal error: Oops: 817 [#1] PREEMPT SMP ARM
>   CPU: 0    Not tainted  (3.5.0-rc5+ #80)
>   PC is at __memzero+0x24/0x80
>   ...
>   Process fsstress (pid: 323, stack limit = 0xc0cbc2f0)
>   Backtrace:
>   [<c010e3f0>] (ext4_getblk+0x0/0x180) from [<c010e58c>] (ext4_bread+0x1c/0x98)
>   [<c010e570>] (ext4_bread+0x0/0x98) from [<c0117944>] (ext4_mkdir+0x160/0x3bc)
>    r4:c15337f0
>   [<c01177e4>] (ext4_mkdir+0x0/0x3bc) from [<c00c29e0>] (vfs_mkdir+0x8c/0x98)
>   [<c00c2954>] (vfs_mkdir+0x0/0x98) from [<c00c2a60>] (sys_mkdirat+0x74/0xac)
>    r6:00000000 r5:c152eb40 r4:000001ff r3:c14b43f0
>   [<c00c29ec>] (sys_mkdirat+0x0/0xac) from [<c00c2ab8>] (sys_mkdir+0x20/0x24)
>    r6:beccdcf0 r5:00074000 r4:beccdbbc
>   [<c00c2a98>] (sys_mkdir+0x0/0x24) from [<c000e3c0>] (ret_fast_syscall+0x0/0x30)
>
(Continue reading)

Girish K S | 9 Jul 10:37 2012

Re: [PATCH RESEND v7 1/2] block: ioctl support for sanitize in eMMC 4.5

On 28 June 2012 14:02, Yaniv Gardi <ygardi <at> codeaurora.org> wrote:
> Adding a new ioctl to support sanitize operation in eMMC
> cards version 4.5.
> The sanitize ioctl support helps performing this operation
> via user application.
>
> Signed-off-by: Yaniv Gardi <ygardi <at> codeaurora.org>
>
> ---
>  block/blk-core.c          |   15 ++++++++++--
>  block/blk-lib.c           |   51 +++++++++++++++++++++++++++++++++++++++++++++
>  block/blk-merge.c         |    4 +++
>  block/elevator.c          |    2 +-
>  block/ioctl.c             |    9 ++++++++
>  include/linux/blk_types.h |    5 +++-
>  include/linux/blkdev.h    |    3 ++
>  include/linux/fs.h        |    1 +
>  kernel/trace/blktrace.c   |    2 +
>  9 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 3c923a7..4a56102b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
>  <at>  <at>  -1641,7 +1641,7  <at>  <at>  generic_make_request_checks(struct bio *bio)
>                 goto end_io;
>         }
>
> -       if (unlikely(!(bio->bi_rw & REQ_DISCARD) &&
> +       if (unlikely(!(bio->bi_rw & (REQ_DISCARD | REQ_SANITIZE)) &&
(Continue reading)

Girish K S | 9 Jul 11:03 2012

Re: [PATCH RESEND v7 1/2] block: ioctl support for sanitize in eMMC 4.5

On 28 June 2012 14:02, Yaniv Gardi <ygardi <at> codeaurora.org> wrote:
> Adding a new ioctl to support sanitize operation in eMMC
> cards version 4.5.
> The sanitize ioctl support helps performing this operation
> via user application.
>
> Signed-off-by: Yaniv Gardi <ygardi <at> codeaurora.org>
>
> ---
>  block/blk-core.c          |   15 ++++++++++--
>  block/blk-lib.c           |   51 +++++++++++++++++++++++++++++++++++++++++++++
>  block/blk-merge.c         |    4 +++
>  block/elevator.c          |    2 +-
>  block/ioctl.c             |    9 ++++++++
>  include/linux/blk_types.h |    5 +++-
>  include/linux/blkdev.h    |    3 ++
>  include/linux/fs.h        |    1 +
>  kernel/trace/blktrace.c   |    2 +
>  9 files changed, 87 insertions(+), 5 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index 3c923a7..4a56102b 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
>  <at>  <at>  -1641,7 +1641,7  <at>  <at>  generic_make_request_checks(struct bio *bio)
>                 goto end_io;
>         }
>
> -       if (unlikely(!(bio->bi_rw & REQ_DISCARD) &&
> +       if (unlikely(!(bio->bi_rw & (REQ_DISCARD | REQ_SANITIZE)) &&
(Continue reading)


Gmane