All of lore.kernel.org
 help / color / mirror / Atom feed
From: Arthur Marsh <arthur.marsh@internode.on.net>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Subject: difficult to pinpoint exhaustion of swap between 4.2.0-rc6 and 4.2.0-rc7
Date: Thu, 20 Aug 2015 01:14:34 +0930	[thread overview]
Message-ID: <55D4A462.3070505@internode.on.net> (raw)

Hi, I've found that the Linus' git head kernel has had some unwelcome 
behaviour where chromium browser would exhaust all swap space in the 
course of a few hours. The behaviour appeared before the release of 
4.2.0-rc7.

This does not happen with kernel 4.2.0-rc6.

When I tried a git-bisect, the results where not conclusive due to the 
problem taking over an hour to appear after booting, the closest I came 
was around this commit (the actual problem may be a few commits either 
side):

git bisect good
4f258a46346c03fa0bbb6199ffaf4e1f9f599660 is the first bad commit
commit 4f258a46346c03fa0bbb6199ffaf4e1f9f599660
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Tue Jun 23 12:13:59 2015 -0400

     sd: Fix maximum I/O size for BLOCK_PC requests

     Commit bcdb247c6b6a ("sd: Limit transfer length") clamped the maximum
     size of an I/O request to the MAXIMUM TRANSFER LENGTH field in the 
BLOCK
     LIMITS VPD. This had the unfortunate effect of also limiting the 
maximum
     size of non-filesystem requests sent to the device through sg/bsg.

     Avoid using blk_queue_max_hw_sectors() and set the max_sectors queue
     limit directly.

     Also update the comment in blk_limits_max_hw_sectors() to clarify that
     max_hw_sectors defines the limit for the I/O controller only.

     Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
     Reported-by: Brian King <brking@linux.vnet.ibm.com>
     Tested-by: Brian King <brking@linux.vnet.ibm.com>
     Cc: stable@vger.kernel.org # 3.17+
     Signed-off-by: James Bottomley <JBottomley@Odin.com>

:040000 040000 fbd0519d9ee0a8f92a7dab9a9c6d7b7868974fba 
b4cf554c568813704993538008aed5b704624679 M      block
:040000 040000 f2630c903cd36ede2619d173f9d1ea0d725ea111 
ff6b6f732afbf6f4b6b26a827c463de50f0e356c M      drivers

Has anyone seen a similar problem?
I can supply .config and other information if requested.

Arthur.

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

WARNING: multiple messages have this Message-ID (diff)
From: Arthur Marsh <arthur.marsh@internode.on.net>
To: linux-mm@kvack.org
Cc: linux-kernel@vger.kernel.org
Subject: difficult to pinpoint exhaustion of swap between 4.2.0-rc6 and 4.2.0-rc7
Date: Thu, 20 Aug 2015 01:14:34 +0930	[thread overview]
Message-ID: <55D4A462.3070505@internode.on.net> (raw)

Hi, I've found that the Linus' git head kernel has had some unwelcome 
behaviour where chromium browser would exhaust all swap space in the 
course of a few hours. The behaviour appeared before the release of 
4.2.0-rc7.

This does not happen with kernel 4.2.0-rc6.

When I tried a git-bisect, the results where not conclusive due to the 
problem taking over an hour to appear after booting, the closest I came 
was around this commit (the actual problem may be a few commits either 
side):

git bisect good
4f258a46346c03fa0bbb6199ffaf4e1f9f599660 is the first bad commit
commit 4f258a46346c03fa0bbb6199ffaf4e1f9f599660
Author: Martin K. Petersen <martin.petersen@oracle.com>
Date:   Tue Jun 23 12:13:59 2015 -0400

     sd: Fix maximum I/O size for BLOCK_PC requests

     Commit bcdb247c6b6a ("sd: Limit transfer length") clamped the maximum
     size of an I/O request to the MAXIMUM TRANSFER LENGTH field in the 
BLOCK
     LIMITS VPD. This had the unfortunate effect of also limiting the 
maximum
     size of non-filesystem requests sent to the device through sg/bsg.

     Avoid using blk_queue_max_hw_sectors() and set the max_sectors queue
     limit directly.

     Also update the comment in blk_limits_max_hw_sectors() to clarify that
     max_hw_sectors defines the limit for the I/O controller only.

     Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
     Reported-by: Brian King <brking@linux.vnet.ibm.com>
     Tested-by: Brian King <brking@linux.vnet.ibm.com>
     Cc: stable@vger.kernel.org # 3.17+
     Signed-off-by: James Bottomley <JBottomley@Odin.com>

:040000 040000 fbd0519d9ee0a8f92a7dab9a9c6d7b7868974fba 
b4cf554c568813704993538008aed5b704624679 M      block
:040000 040000 f2630c903cd36ede2619d173f9d1ea0d725ea111 
ff6b6f732afbf6f4b6b26a827c463de50f0e356c M      drivers

Has anyone seen a similar problem?
I can supply .config and other information if requested.

Arthur.


             reply	other threads:[~2015-08-19 15:45 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-19 15:44 Arthur Marsh [this message]
2015-08-19 15:44 ` difficult to pinpoint exhaustion of swap between 4.2.0-rc6 and 4.2.0-rc7 Arthur Marsh
2015-08-20  8:16 ` Vlastimil Babka
2015-08-20  8:16   ` Vlastimil Babka
2015-08-21  9:17   ` Arthur Marsh
2015-08-21 11:37     ` Vlastimil Babka
2015-08-21 11:37       ` Vlastimil Babka
2015-08-21 11:48       ` Vlastimil Babka
2015-08-21 11:48         ` Vlastimil Babka
2015-08-21 12:43         ` Arthur Marsh
2015-08-21 12:43           ` Arthur Marsh
2015-08-22  4:48         ` Arthur Marsh
2015-08-22  4:48           ` Arthur Marsh
2015-08-22  7:05           ` Vlastimil Babka
2015-08-22  7:05             ` Vlastimil Babka
2015-08-21 12:38       ` Arthur Marsh
2015-08-21 12:38         ` Arthur Marsh

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=55D4A462.3070505@internode.on.net \
    --to=arthur.marsh@internode.on.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    /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.