From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Martin K. Petersen" Subject: LSF/MM 2016: Call for Proposals Date: Tue, 12 Jan 2016 11:05:45 -0500 Message-ID: Mime-Version: 1.0 Content-Type: text/plain Cc: lsf-pc@lists.linux-foundation.org To: linux-block@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-scsi@vger.kernel.org, xfs@oss.sgi.com Return-path: Sender: owner-linux-mm@kvack.org List-Id: linux-cifs.vger.kernel.org The annual Linux Storage, Filesystem and Memory Management Summit for 2016 will be held on April 18th and 19th at the Raleigh Marriott City center, Raleigh, NC. Like last year, LSF/MM will be colocated with the Linux Foundation Vault conference which takes place on April 20th and 21st in the same venue. For those that do not know, Vault is designed to be an event where open source storage and filesystem practitioners meet storage implementors and, as such, it would be of benefit for LSF/MM attendees to attend. http://events.linuxfoundation.org/events/linux-storage-filesystem-and-mm-summit http://events.linuxfoundation.org/events/vault On behalf of the committee I am issuing a call for agenda proposals that are suitable for cross-track discussion as well as technical subjects for the breakout sessions. 1) Proposals for agenda topics should be sent before February 29th, 2016 to: lsf-pc@lists.linux-foundation.org and cc the Linux list or lists that are relevant for the topic in question: ATA: linux-ide@vger.kernel.org Block: linux-block@vger.kernel.org FS: linux-fsdevel@vger.kernel.org MM: linux-mm@kvack.org SCSI: linux-scsi@vger.kernel.org If advance notice is required for visa applications then please send proposals before February 11th. The committee will complete the first round of selections near that date to accommodate applications. Please tag your proposal with [LSF/MM TOPIC] to make it easier to track. In addition, please make sure to start a new thread for each topic rather than following up to an existing one. Agenda topics and attendees will be selected by the program committee, but the final agenda will be formed by consensus of the attendees at the summit. We will try to cap attendance at around 25-30 per track to facilitate discussions, although the final numbers will depend on the room sizes at the venue. 2) Requests to attend the summit should be sent to: lsf-pc@lists.linux-foundation.org Please summarise what expertise you will bring to the meeting, and what you would like to discuss. Please also tag your email with [LSF/MM ATTEND] so there is less chance of it getting lost. Presentations are allowed to guide discussion, but are strongly discouraged. There will be no recording or audio bridge. However, we expect that written minutes will be published as we did in previous years 2015: https://lwn.net/Articles/lsfmm2015/ 2014: http://lwn.net/Articles/LSFMM2014/ 2013: http://lwn.net/Articles/548089/ 3) If you have feedback on last year's meeting that we can use to improve this year's, please also send that to: lsf-pc@lists.linux-foundation.org Thank you on behalf of the program committee: Storage: Jens Axboe (track chair) James Bottomley Christoph Hellwig Martin K. Petersen (program chair) Filesystems: Josef Bacik Jan Kara Jeff Layton (track chair) Anna Schumaker Theodore Ts'o Ric Wheeler MM: Mel Gorman Johannes Weiner Rik van Riel (track chair) -- Martin K. Petersen Oracle Linux Engineering -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from aserp1040.oracle.com ([141.146.126.69]:49603 "EHLO aserp1040.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1762209AbcALQGE (ORCPT ); Tue, 12 Jan 2016 11:06:04 -0500 To: linux-block@vger.kernel.org, linux-btrfs@vger.kernel.org, linux-cifs@vger.kernel.org, linux-ext4@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-ide@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, linux-nfs@vger.kernel.org, linux-scsi@vger.kernel.org, xfs@oss.sgi.com Cc: lsf-pc@lists.linux-foundation.org Subject: LSF/MM 2016: Call for Proposals From: "Martin K. Petersen" Date: Tue, 12 Jan 2016 11:05:45 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Sender: linux-btrfs-owner@vger.kernel.org List-ID: The annual Linux Storage, Filesystem and Memory Management Summit for 2016 will be held on April 18th and 19th at the Raleigh Marriott City center, Raleigh, NC. Like last year, LSF/MM will be colocated with the Linux Foundation Vault conference which takes place on April 20th and 21st in the same venue. For those that do not know, Vault is designed to be an event where open source storage and filesystem practitioners meet storage implementors and, as such, it would be of benefit for LSF/MM attendees to attend. http://events.linuxfoundation.org/events/linux-storage-filesystem-and-mm-summit http://events.linuxfoundation.org/events/vault On behalf of the committee I am issuing a call for agenda proposals that are suitable for cross-track discussion as well as technical subjects for the breakout sessions. 1) Proposals for agenda topics should be sent before February 29th, 2016 to: lsf-pc@lists.linux-foundation.org and cc the Linux list or lists that are relevant for the topic in question: ATA: linux-ide@vger.kernel.org Block: linux-block@vger.kernel.org FS: linux-fsdevel@vger.kernel.org MM: linux-mm@kvack.org SCSI: linux-scsi@vger.kernel.org If advance notice is required for visa applications then please send proposals before February 11th. The committee will complete the first round of selections near that date to accommodate applications. Please tag your proposal with [LSF/MM TOPIC] to make it easier to track. In addition, please make sure to start a new thread for each topic rather than following up to an existing one. Agenda topics and attendees will be selected by the program committee, but the final agenda will be formed by consensus of the attendees at the summit. We will try to cap attendance at around 25-30 per track to facilitate discussions, although the final numbers will depend on the room sizes at the venue. 2) Requests to attend the summit should be sent to: lsf-pc@lists.linux-foundation.org Please summarise what expertise you will bring to the meeting, and what you would like to discuss. Please also tag your email with [LSF/MM ATTEND] so there is less chance of it getting lost. Presentations are allowed to guide discussion, but are strongly discouraged. There will be no recording or audio bridge. However, we expect that written minutes will be published as we did in previous years 2015: https://lwn.net/Articles/lsfmm2015/ 2014: http://lwn.net/Articles/LSFMM2014/ 2013: http://lwn.net/Articles/548089/ 3) If you have feedback on last year's meeting that we can use to improve this year's, please also send that to: lsf-pc@lists.linux-foundation.org Thank you on behalf of the program committee: Storage: Jens Axboe (track chair) James Bottomley Christoph Hellwig Martin K. Petersen (program chair) Filesystems: Josef Bacik Jan Kara Jeff Layton (track chair) Anna Schumaker Theodore Ts'o Ric Wheeler MM: Mel Gorman Johannes Weiner Rik van Riel (track chair) -- Martin K. Petersen Oracle Linux Engineering From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:46021 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756124AbcAOKyw (ORCPT ); Fri, 15 Jan 2016 05:54:52 -0500 Subject: [LSF/MM ATTEND] [LSF/MM TOPIC] Request to attend and for topic of "Block & Filesystem interface" To: linux-fsdevel@vger.kernel.org, lsf-pc@lists.linux-foundation.org, linux-block@vger.kernel.org References: From: Steven Whitehouse Message-ID: <5698CFF8.3010605@redhat.com> Date: Fri, 15 Jan 2016 10:54:48 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi, I'd like to attend this years LSF/MM and I'd like to propose a reprise of the "Block & Filesystem interface" topic that was discussed last year. It seemed to generate quite a lot of discussion last time - in fact rather more than could easily be squeezed into its timeslot :-) My plan for this year would be to do something similar, if it is accepted. So just a very few slides summarizing the current situation, whats changed since last year, and anything new on the horizon, to help kick off the discussion. I'm also interested in a very wide range of filesytems, storage and mm topics, including GFS2, NFS, XFS, ext*, autofs, fedfs, CIFS and technologies such as DAX, dedup, compression and encryption, Steve. On 12/01/16 16:05, Martin K. Petersen wrote: > The annual Linux Storage, Filesystem and Memory Management Summit for > 2016 will be held on April 18th and 19th at the Raleigh Marriott City > center, Raleigh, NC. > > Like last year, LSF/MM will be colocated with the Linux Foundation Vault > conference which takes place on April 20th and 21st in the same > venue. For those that do not know, Vault is designed to be an event > where open source storage and filesystem practitioners meet storage > implementors and, as such, it would be of benefit for LSF/MM attendees > to attend. > > http://events.linuxfoundation.org/events/linux-storage-filesystem-and-mm-summit > http://events.linuxfoundation.org/events/vault > > On behalf of the committee I am issuing a call for agenda proposals that > are suitable for cross-track discussion as well as technical subjects > for the breakout sessions. > > 1) Proposals for agenda topics should be sent before February 29th, 2016 > to: > > lsf-pc@lists.linux-foundation.org > > and cc the Linux list or lists that are relevant for the topic in > question: > > ATA: linux-ide@vger.kernel.org > Block: linux-block@vger.kernel.org > FS: linux-fsdevel@vger.kernel.org > MM: linux-mm@kvack.org > SCSI: linux-scsi@vger.kernel.org > > If advance notice is required for visa applications then please send > proposals before February 11th. The committee will complete the first > round of selections near that date to accommodate applications. > > Please tag your proposal with [LSF/MM TOPIC] to make it easier to > track. In addition, please make sure to start a new thread for each > topic rather than following up to an existing one. > > Agenda topics and attendees will be selected by the program committee, > but the final agenda will be formed by consensus of the attendees at the > summit. > > We will try to cap attendance at around 25-30 per track to facilitate > discussions, although the final numbers will depend on the room sizes at > the venue. > > 2) Requests to attend the summit should be sent to: > > lsf-pc@lists.linux-foundation.org > > Please summarise what expertise you will bring to the meeting, and what > you would like to discuss. Please also tag your email with [LSF/MM > ATTEND] so there is less chance of it getting lost. > > Presentations are allowed to guide discussion, but are strongly > discouraged. There will be no recording or audio bridge. However, we > expect that written minutes will be published as we did in previous > years > > 2015: > https://lwn.net/Articles/lsfmm2015/ > > 2014: > http://lwn.net/Articles/LSFMM2014/ > > 2013: > http://lwn.net/Articles/548089/ > > 3) If you have feedback on last year's meeting that we can use to > improve this year's, please also send that to: > > lsf-pc@lists.linux-foundation.org > > Thank you on behalf of the program committee: > > Storage: > Jens Axboe (track chair) > James Bottomley > Christoph Hellwig > Martin K. Petersen (program chair) > > Filesystems: > Josef Bacik > Jan Kara > Jeff Layton (track chair) > Anna Schumaker > Theodore Ts'o > Ric Wheeler > > MM: > Mel Gorman > Johannes Weiner > Rik van Riel (track chair) > From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f52.google.com (mail-qg0-f52.google.com [209.85.192.52]) by kanga.kvack.org (Postfix) with ESMTP id 809FD828DF for ; Fri, 15 Jan 2016 03:10:58 -0500 (EST) Received: by mail-qg0-f52.google.com with SMTP id e32so414242564qgf.3 for ; Fri, 15 Jan 2016 00:10:58 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id n130si12055584qhc.118.2016.01.15.00.10.57 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Jan 2016 00:10:57 -0800 (PST) Date: Fri, 15 Jan 2016 09:10:51 +0100 From: Jesper Dangaard Brouer Subject: [LSF/MM ATTEND] 2016: Requests to attend MM-summit Message-ID: <20160115091051.03715530@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Martin K. Petersen" , lsf-pc@lists.linux-foundation.org Cc: brouer@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Christoph Lameter On Tue, 12 Jan 2016 11:05:45 -0500 "Martin K. Petersen" wrote: > The annual Linux Storage, Filesystem and Memory Management Summit for > 2016 will be held on April 18th and 19th at the Raleigh Marriott City > center, Raleigh, NC. > [...] > > 2) Requests to attend the summit should be sent to: > > lsf-pc@lists.linux-foundation.org > > Please summarise what expertise you will bring to the meeting, and what > you would like to discuss. Please also tag your email with [LSF/MM > ATTEND] so there is less chance of it getting lost. Hi committee, I would like to participate in LSF/MM. I've over the last year optimized the SLAB+SLUB allocators, specifically by introducing a bulking API. This work is almost complete, but I have some more ideas in the MM-area that I would like to discuss with people. Specifically I have the following ideas: 1. Speedup *SLUB* with approx 10-20% by using per CPU detached freelists for all types of allocations/free. * Actually have a prove-of-concept implementation that showed 20% speedup * Idea is every page (used-by SLUB) gets a detached freelist * The first CPU that alloc the page, owns this detached freelist * CPU owning page can do sync free operation on this freelist. * SLUB is already highly biased to keep objects on same CPU 2. Bulk alloc without disabling IRQ (SLUB) * This is something Real-Time (RT) people will be screaming for, once more users of bulk API starts to appear. * I think it is doable, but also very challenging to keep performance 3. Faster memset clearing of memory in SLUB * Currently netstack clears SKBs right after alloc (2-3% in perf) * In SLUB allocator we could clear larger section of memory which is significantly faster. * Bulk alloc would be the right spot * Difficult part is inventing an algorithm for matching contiguous mem, which is fast-enough, as the est. time budget is 15-20 cycles. 4. Bulk free from RCU context * One major slowdown of using RCU free is, that free will always hit SLUB slowpath. We could change this via bulk free API. * This would be a major benefit for the entire kernel performance. * The challenge here is getting to know the RCU free code well-enough -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by kanga.kvack.org (Postfix) with ESMTP id EE201828DF for ; Fri, 15 Jan 2016 11:49:34 -0500 (EST) Received: by mail-ig0-f171.google.com with SMTP id mw1so13830873igb.1 for ; Fri, 15 Jan 2016 08:49:34 -0800 (PST) Received: from resqmta-ch2-05v.sys.comcast.net (resqmta-ch2-05v.sys.comcast.net. [2001:558:fe21:29:69:252:207:37]) by mx.google.com with ESMTPS id m9si6259827ige.60.2016.01.15.08.49.34 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Fri, 15 Jan 2016 08:49:34 -0800 (PST) Date: Fri, 15 Jan 2016 10:49:33 -0600 (CST) From: Christoph Lameter Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit In-Reply-To: <20160115091051.03715530@redhat.com> Message-ID: References: <20160115091051.03715530@redhat.com> Content-Type: text/plain; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Jesper Dangaard Brouer Cc: "Martin K. Petersen" , lsf-pc@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org On Fri, 15 Jan 2016, Jesper Dangaard Brouer wrote: > I've over the last year optimized the SLAB+SLUB allocators, > specifically by introducing a bulking API. This work is almost > complete, but I have some more ideas in the MM-area that I would like > to discuss with people. I think this is pretty good work which can help a lot for subsystems dealing with large amounts of objects. Given that network speeds and memory increases we may have to look increasingly at bulk allocation to make further strides in MM performance by rewriting subsystems to take advantage of these features. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by kanga.kvack.org (Postfix) with ESMTP id 1BEC66B0005 for ; Thu, 21 Jan 2016 23:41:19 -0500 (EST) Received: by mail-pf0-f177.google.com with SMTP id n128so35207482pfn.3 for ; Thu, 21 Jan 2016 20:41:19 -0800 (PST) Received: from e28smtp02.in.ibm.com (e28smtp02.in.ibm.com. [125.16.236.2]) by mx.google.com with ESMTPS id gy5si6782613pac.83.2016.01.21.20.41.17 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 21 Jan 2016 20:41:18 -0800 (PST) Received: from localhost by e28smtp02.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 22 Jan 2016 10:11:15 +0530 Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay01.in.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0M4fD7c44892252 for ; Fri, 22 Jan 2016 10:11:14 +0530 Received: from d28av03.in.ibm.com (localhost [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0M4fDqg026753 for ; Fri, 22 Jan 2016 10:11:13 +0530 From: "Aneesh Kumar K.V" Subject: [LSF/MM ATTEND] 2016: Requests to attend MM-summit Date: Fri, 22 Jan 2016 10:11:12 +0530 Message-ID: <87k2n2usyf.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Sender: owner-linux-mm@kvack.org List-ID: To: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org Hi, I would like to attend LSF/MM this year (2016). My main interest is in MM related topics although I am also interested in the btrfs status discussion (particularly related to subpage size block size topic), if we are having one. Most of my recent work in the kernel is related to adding ppc64 support for different MM features. My current focus is on adding Linux support for the new radix MMU model of Power9. Topics of interest include: * CMA allocator issues: (1) order zero allocation failures: We are observing order zero non-movable allocation failures in kernel with CMA configured. We don't start a reclaim because our free memory check does not consider free_cma. Hence the reclaim code assume we have enough fr= ee pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would like to discuss the challenges in getting this merged upstream. https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA) Others needed for the discussion: Joonsoo Kim (2) CMA allocation failures due to pinned pages in the region: We allow only movable allocation from the CMA region to enable us to migrate those pages later when we get a CMA allocation request. But if we pin those movable pages, we will fail the migration which can result in CMA allocation failure. One such report can be found here. http://article.gmane.org/gmane.linux.kernel.mm/136738 Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I = would like to discuss what needs to be done to get this patch series merged upstr= eam https://lkml.org/lkml/2014/5/26/345 (VM_PINNED) Others needed for the discussion: Peter Zijlstra * Improvements to tlb flush Archiectures like ppc64 can do range based tlb flush and for that we ne= ed to know the page size used to map the virtual address range. I would like to discuss changes to mmu gather and tlb flush api that will help in effici= ent implementation of tlb flush for ppc64. (1) MMU gather improvements https://github.com/kvaneesh/linux/commit/215b9c7c03bb8d742349e2aefaa= dcf8cc0c04dd8 https://github.com/kvaneesh/linux/commit/43bd9e91a841bbc9e3c6ee56a4d= 12ed00019718c (2) different APIs to flush hugepage tlb mappings. https://github.com/kvaneesh/linux/commit/b8a78933fea93cb0b2978868e59= a0a4b12eb92eb https://github.com/kvaneesh/linux/commit/049d361a59a3342c2ce5a4feae6= 1dce4974af226 NOTE: I haven't posted these changes yet to the list because of dependent p= atches getting reviewed. But should have them available on the list before LSF/MM. * HMM status (Heterogeneous Memory Management) I would like to discuss the roadblocks w.r.t merging HMM patchset upstrea= m. http://article.gmane.org/gmane.linux.kernel.mm/140229 Others needed for the discussion: J=C3=A9r=C3=B4me Glisse -aneesh -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) by kanga.kvack.org (Postfix) with ESMTP id AD9326B0005 for ; Fri, 22 Jan 2016 04:17:16 -0500 (EST) Received: by mail-pf0-f177.google.com with SMTP id q63so40299440pfb.1 for ; Fri, 22 Jan 2016 01:17:16 -0800 (PST) Received: from mail-pa0-x22f.google.com (mail-pa0-x22f.google.com. [2607:f8b0:400e:c03::22f]) by mx.google.com with ESMTPS id xk9si8396326pab.38.2016.01.22.01.17.15 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2016 01:17:16 -0800 (PST) Received: by mail-pa0-x22f.google.com with SMTP id uo6so39471786pac.1 for ; Fri, 22 Jan 2016 01:17:15 -0800 (PST) Date: Fri, 22 Jan 2016 20:17:07 +1100 From: Balbir Singh Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit Message-ID: <20160122201707.1271a279@cotter.ozlabs.ibm.com> In-Reply-To: <87k2n2usyf.fsf@linux.vnet.ibm.com> References: <87k2n2usyf.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: "Aneesh Kumar K.V" Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org On Fri, 22 Jan 2016 10:11:12 +0530 "Aneesh Kumar K.V" wrote: > Hi, > > I would like to attend LSF/MM this year (2016). > > My main interest is in MM related topics although I am also interested > in the btrfs status discussion (particularly related to subpage size block > size topic), if we are having one. Most of my recent work in the kernel is > related to adding ppc64 support for different MM features. My current focus > is on adding Linux support for the new radix MMU model of Power9. > > Topics of interest include: > > * CMA allocator issues: > (1) order zero allocation failures: > We are observing order zero non-movable allocation failures in kernel > with CMA configured. We don't start a reclaim because our free memory check > does not consider free_cma. Hence the reclaim code assume we have enough free > pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would > like to discuss the challenges in getting this merged upstream. > https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA) > > Others needed for the discussion: > Joonsoo Kim > > (2) CMA allocation failures due to pinned pages in the region: > We allow only movable allocation from the CMA region to enable us > to migrate those pages later when we get a CMA allocation request. But > if we pin those movable pages, we will fail the migration which can result > in CMA allocation failure. One such report can be found here. > http://article.gmane.org/gmane.linux.kernel.mm/136738 > > Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would > like to discuss what needs to be done to get this patch series merged upstream > https://lkml.org/lkml/2014/5/26/345 (VM_PINNED) > > Others needed for the discussion: > Peter Zijlstra +1 I agree CMA design is a concern. I also noticed that today all CMA pages come from one node. On a NUMA box you'll see cross traffic going to that region - although from kernel only text. It should be discussed at the summit and Aneesh would be a good representative Balbir Singh. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f50.google.com (mail-wm0-f50.google.com [74.125.82.50]) by kanga.kvack.org (Postfix) with ESMTP id 6959C6B0005 for ; Fri, 22 Jan 2016 11:38:12 -0500 (EST) Received: by mail-wm0-f50.google.com with SMTP id b14so141053535wmb.1 for ; Fri, 22 Jan 2016 08:38:12 -0800 (PST) Received: from gum.cmpxchg.org (gum.cmpxchg.org. [85.214.110.215]) by mx.google.com with ESMTPS id m64si5236391wma.122.2016.01.22.08.38.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Jan 2016 08:38:11 -0800 (PST) Date: Fri, 22 Jan 2016 11:38:01 -0500 From: Johannes Weiner Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit Message-ID: <20160122163801.GA16668@cmpxchg.org> References: <87k2n2usyf.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87k2n2usyf.fsf@linux.vnet.ibm.com> Sender: owner-linux-mm@kvack.org List-ID: To: "Aneesh Kumar K.V" Cc: lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Joonsoo Kim , Peter Zijlstra Hi, On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote: > * CMA allocator issues: > (1) order zero allocation failures: > We are observing order zero non-movable allocation failures in kernel > with CMA configured. We don't start a reclaim because our free memory check > does not consider free_cma. Hence the reclaim code assume we have enough free > pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would > like to discuss the challenges in getting this merged upstream. > https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA) The exclusion of cma pages from the watermark checks means that reclaim is happening too early, not too late, which leaves memory underutilized. That's what ZONE_CMA set out to fix. But unmovable allocations can still fail when the only free memory is inside CMA regions. I don't see how ZONE_CMA would fix that. CC Joonsoo But as Jan said, we discussed ZONE_CMA before, so it's not clear whether rehashing it without new data points would be too useful. > Others needed for the discussion: > Joonsoo Kim > > (2) CMA allocation failures due to pinned pages in the region: > We allow only movable allocation from the CMA region to enable us > to migrate those pages later when we get a CMA allocation request. But > if we pin those movable pages, we will fail the migration which can result > in CMA allocation failure. One such report can be found here. > http://article.gmane.org/gmane.linux.kernel.mm/136738 > > Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would > like to discuss what needs to be done to get this patch series merged upstream > https://lkml.org/lkml/2014/5/26/345 (VM_PINNED) > > Others needed for the discussion: > Peter Zijlstra There was no consensus whether this specific implementation would work well for all sources of pinning. Giving this some time in the MM track could be useful. CC Peter -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ob0-f170.google.com (mail-ob0-f170.google.com [209.85.214.170]) by kanga.kvack.org (Postfix) with ESMTP id DA99B6B0005 for ; Mon, 25 Jan 2016 02:08:10 -0500 (EST) Received: by mail-ob0-f170.google.com with SMTP id vt7so108973358obb.1 for ; Sun, 24 Jan 2016 23:08:10 -0800 (PST) Received: from mail-oi0-x22c.google.com (mail-oi0-x22c.google.com. [2607:f8b0:4003:c06::22c]) by mx.google.com with ESMTPS id rx2si15909439oeb.11.2016.01.24.23.08.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 24 Jan 2016 23:08:10 -0800 (PST) Received: by mail-oi0-x22c.google.com with SMTP id w75so82008584oie.0 for ; Sun, 24 Jan 2016 23:08:10 -0800 (PST) MIME-Version: 1.0 In-Reply-To: <20160122163801.GA16668@cmpxchg.org> References: <87k2n2usyf.fsf@linux.vnet.ibm.com> <20160122163801.GA16668@cmpxchg.org> Date: Mon, 25 Jan 2016 16:08:09 +0900 Message-ID: Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit From: Joonsoo Kim Content-Type: text/plain; charset=UTF-8 Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: "Aneesh Kumar K.V" , lsf-pc@lists.linux-foundation.org, Linux Memory Management List , Joonsoo Kim , Peter Zijlstra Hello, 2016-01-23 1:38 GMT+09:00 Johannes Weiner : > Hi, > > On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote: >> * CMA allocator issues: >> (1) order zero allocation failures: >> We are observing order zero non-movable allocation failures in kernel >> with CMA configured. We don't start a reclaim because our free memory check >> does not consider free_cma. Hence the reclaim code assume we have enough free >> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would >> like to discuss the challenges in getting this merged upstream. >> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA) As far as I know, there is no disagreement on this patchset in last year LSF/MM. Problem may be due to my laziness... Sorry about that. I will handle it soon. Is there anything more that you concern? > The exclusion of cma pages from the watermark checks means that > reclaim is happening too early, not too late, which leaves memory > underutilized. That's what ZONE_CMA set out to fix. > > But unmovable allocations can still fail when the only free memory is > inside CMA regions. I don't see how ZONE_CMA would fix that. > > CC Joonsoo I understand what Aneesh's problem is. Assume that X = non movable free page Y = movable free page Z = cma free page X < min watermark X + Y > high watermark Z > high watermark If there are bunch of consecutive movable allocation requests, Y will decrease. After some time, Y will be exhausted. At that time, there is enough Z so movable allocation request still can be handled in fastpath and kswapd isn't waked up. In that situation, if atomic non-movable page allocation for order-0 comes, it would be failed. Although it isn't mentioned on ZONE_CMA patchset, it is also fixed by that patchset because with that patchset, all CMA pages are in CMA zone so freepage calculation is always precise. Thanks. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qg0-f46.google.com (mail-qg0-f46.google.com [209.85.192.46]) by kanga.kvack.org (Postfix) with ESMTP id 888BA6B0009 for ; Mon, 25 Jan 2016 18:37:11 -0500 (EST) Received: by mail-qg0-f46.google.com with SMTP id o11so121944307qge.2 for ; Mon, 25 Jan 2016 15:37:11 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id y69si27135511qka.73.2016.01.25.15.37.10 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 25 Jan 2016 15:37:10 -0800 (PST) Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit References: <87k2n2usyf.fsf@linux.vnet.ibm.com> <20160122163801.GA16668@cmpxchg.org> From: Laura Abbott Message-ID: <56A6B1A2.40903@redhat.com> Date: Mon, 25 Jan 2016 15:37:06 -0800 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim , Johannes Weiner Cc: "Aneesh Kumar K.V" , lsf-pc@lists.linux-foundation.org, Linux Memory Management List , Joonsoo Kim , Peter Zijlstra On 01/24/2016 11:08 PM, Joonsoo Kim wrote: > Hello, > > 2016-01-23 1:38 GMT+09:00 Johannes Weiner : >> Hi, >> >> On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote: >>> * CMA allocator issues: >>> (1) order zero allocation failures: >>> We are observing order zero non-movable allocation failures in kernel >>> with CMA configured. We don't start a reclaim because our free memory check >>> does not consider free_cma. Hence the reclaim code assume we have enough free >>> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would >>> like to discuss the challenges in getting this merged upstream. >>> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA) > > As far as I know, there is no disagreement on this patchset in last year LSF/MM. > Problem may be due to my laziness... Sorry about that. I will handle it soon. > Is there anything more that you concern? > Is that series going to conflict with the work done for ZONE_DEVICE or run into similar problems? 033fbae988fcb67e5077203512181890848b8e90 (mm: ZONE_DEVICE for "device memory") has commit text about running out of ZONE_SHIFT bits and needing to get rid of ZONE_DMA instead so it seems like ZONE_CMA would run into the same problem. Thanks, Laura >> The exclusion of cma pages from the watermark checks means that >> reclaim is happening too early, not too late, which leaves memory >> underutilized. That's what ZONE_CMA set out to fix. >> >> But unmovable allocations can still fail when the only free memory is >> inside CMA regions. I don't see how ZONE_CMA would fix that. >> >> CC Joonsoo > > I understand what Aneesh's problem is. > > Assume that > > X = non movable free page > Y = movable free page > Z = cma free page > > X < min watermark > X + Y > high watermark > Z > high watermark > > If there are bunch of consecutive movable allocation requests, > Y will decrease. After some time, Y will be exhausted. At that > time, there is enough Z so movable allocation request still can be > handled in fastpath and kswapd isn't waked up. In that situation, > if atomic non-movable page allocation for order-0 comes, > it would be failed. > > Although it isn't mentioned on ZONE_CMA patchset, it is also > fixed by that patchset because with that patchset, all CMA pages > are in CMA zone so freepage calculation is always precise. > > Thanks. > > -- > 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: email@kvack.org > -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pa0-f46.google.com (mail-pa0-f46.google.com [209.85.220.46]) by kanga.kvack.org (Postfix) with ESMTP id 621B06B0005 for ; Tue, 26 Jan 2016 02:38:31 -0500 (EST) Received: by mail-pa0-f46.google.com with SMTP id cy9so94153446pac.0 for ; Mon, 25 Jan 2016 23:38:31 -0800 (PST) Received: from lgeamrelo11.lge.com (LGEAMRELO11.lge.com. [156.147.23.51]) by mx.google.com with ESMTPS id p13si95195pfi.234.2016.01.25.23.38.29 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 25 Jan 2016 23:38:30 -0800 (PST) Date: Tue, 26 Jan 2016 16:38:46 +0900 From: Joonsoo Kim Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit Message-ID: <20160126073846.GC28254@js1304-P5Q-DELUXE> References: <87k2n2usyf.fsf@linux.vnet.ibm.com> <20160122163801.GA16668@cmpxchg.org> <56A6B1A2.40903@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56A6B1A2.40903@redhat.com> Sender: owner-linux-mm@kvack.org List-ID: To: Laura Abbott Cc: Johannes Weiner , "Aneesh Kumar K.V" , lsf-pc@lists.linux-foundation.org, Linux Memory Management List , Peter Zijlstra On Mon, Jan 25, 2016 at 03:37:06PM -0800, Laura Abbott wrote: > On 01/24/2016 11:08 PM, Joonsoo Kim wrote: > >Hello, > > > >2016-01-23 1:38 GMT+09:00 Johannes Weiner : > >>Hi, > >> > >>On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote: > >>>* CMA allocator issues: > >>> (1) order zero allocation failures: > >>> We are observing order zero non-movable allocation failures in kernel > >>>with CMA configured. We don't start a reclaim because our free memory check > >>>does not consider free_cma. Hence the reclaim code assume we have enough free > >>>pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would > >>>like to discuss the challenges in getting this merged upstream. > >>>https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA) > > > >As far as I know, there is no disagreement on this patchset in last year LSF/MM. > >Problem may be due to my laziness... Sorry about that. I will handle it soon. > >Is there anything more that you concern? > > > > Is that series going to conflict with the work done for ZONE_DEVICE or run > into similar problems? > 033fbae988fcb67e5077203512181890848b8e90 (mm: ZONE_DEVICE for "device memory") > has commit text about running out of ZONE_SHIFT bits and needing to get > rid of ZONE_DMA instead so it seems like ZONE_CMA would run into the same > problem. Hmm... I'm not sure. I need a investigation. What I did before is enlarging section size. Then, number of section is reduced and we need less section bit in struct page's flag. This worked for my sparsemem configuration but I'm not sure other conguration. Perhaps, in other congifuration, we can limit node bits and max number of node. Thanks. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f54.google.com (mail-wm0-f54.google.com [74.125.82.54]) by kanga.kvack.org (Postfix) with ESMTP id D4C726B0005 for ; Tue, 26 Jan 2016 13:53:49 -0500 (EST) Received: by mail-wm0-f54.google.com with SMTP id u188so119135136wmu.1 for ; Tue, 26 Jan 2016 10:53:49 -0800 (PST) Received: from mx2.suse.de (mx2.suse.de. [195.135.220.15]) by mx.google.com with ESMTPS id lz8si3477317wjb.121.2016.01.26.10.53.48 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 26 Jan 2016 10:53:48 -0800 (PST) Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit References: <87k2n2usyf.fsf@linux.vnet.ibm.com> <20160122163801.GA16668@cmpxchg.org> <56A6B1A2.40903@redhat.com> <20160126073846.GC28254@js1304-P5Q-DELUXE> From: Vlastimil Babka Message-ID: <56A7C0B9.7040701@suse.cz> Date: Tue, 26 Jan 2016 19:53:45 +0100 MIME-Version: 1.0 In-Reply-To: <20160126073846.GC28254@js1304-P5Q-DELUXE> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim , Laura Abbott Cc: Johannes Weiner , "Aneesh Kumar K.V" , lsf-pc@lists.linux-foundation.org, Linux Memory Management List , Peter Zijlstra On 26.1.2016 8:38, Joonsoo Kim wrote: > On Mon, Jan 25, 2016 at 03:37:06PM -0800, Laura Abbott wrote: >> >> Is that series going to conflict with the work done for ZONE_DEVICE or run >> into similar problems? >> 033fbae988fcb67e5077203512181890848b8e90 (mm: ZONE_DEVICE for "device memory") >> has commit text about running out of ZONE_SHIFT bits and needing to get >> rid of ZONE_DMA instead so it seems like ZONE_CMA would run into the same >> problem. > > Hmm... I'm not sure. I need a investigation. What I did before is > enlarging section size. Then, number of section is reduced and we need > less section bit in struct page's flag. This worked for my sparsemem > configuration but I'm not sure other conguration. Perhaps, in other > congifuration, we can limit node bits and max number of node. This seems to be a solution proposed for the ZONE_DMA and ZONE_DEVICE coexistence https://lkml.org/lkml/2016/1/25/1233 It wouldn't help with ZONE_CMA, so I guess it's time to look for a more robust one. > Thanks. > > -- > 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: email@kvack.org > -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com [209.85.192.176]) by kanga.kvack.org (Postfix) with ESMTP id 474046B0258 for ; Wed, 27 Jan 2016 13:32:10 -0500 (EST) Received: by mail-pf0-f176.google.com with SMTP id 65so8813837pfd.2 for ; Wed, 27 Jan 2016 10:32:10 -0800 (PST) Received: from bombadil.infradead.org (bombadil.infradead.org. [2001:1868:205::9]) by mx.google.com with ESMTPS id km8si10918102pab.198.2016.01.27.10.32.09 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Jan 2016 10:32:09 -0800 (PST) Date: Wed, 27 Jan 2016 19:32:05 +0100 From: Peter Zijlstra Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit Message-ID: <20160127183205.GY6357@twins.programming.kicks-ass.net> References: <87k2n2usyf.fsf@linux.vnet.ibm.com> <20160122163801.GA16668@cmpxchg.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160122163801.GA16668@cmpxchg.org> Sender: owner-linux-mm@kvack.org List-ID: To: Johannes Weiner Cc: "Aneesh Kumar K.V" , lsf-pc@lists.linux-foundation.org, linux-mm@kvack.org, Joonsoo Kim On Fri, Jan 22, 2016 at 11:38:01AM -0500, Johannes Weiner wrote: > > > > Peter Zijlstra's VM_PINNED patch series should help in fixing the issue. I would > > like to discuss what needs to be done to get this patch series merged upstream > > https://lkml.org/lkml/2014/5/26/345 (VM_PINNED) > > > > Others needed for the discussion: > > Peter Zijlstra > > There was no consensus whether this specific implementation would work > well for all sources of pinning. Giving this some time in the MM track > could be useful. I got stuck and lost in IB land. But that was a fair while ago. I should probably look at rebasing it against something recent, although I seriuosly doubt I can get through IB this time. -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f180.google.com (mail-pf0-f180.google.com [209.85.192.180]) by kanga.kvack.org (Postfix) with ESMTP id 44EEA6B0256 for ; Thu, 28 Jan 2016 04:44:46 -0500 (EST) Received: by mail-pf0-f180.google.com with SMTP id o185so16331159pfb.1 for ; Thu, 28 Jan 2016 01:44:46 -0800 (PST) Received: from e23smtp09.au.ibm.com (e23smtp09.au.ibm.com. [202.81.31.142]) by mx.google.com with ESMTPS id x12si781998pfa.98.2016.01.28.01.44.44 for (version=TLS1 cipher=AES128-SHA bits=128/128); Thu, 28 Jan 2016 01:44:45 -0800 (PST) Received: from localhost by e23smtp09.au.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 28 Jan 2016 19:44:37 +1000 Received: from d23relay07.au.ibm.com (d23relay07.au.ibm.com [9.190.26.37]) by d23dlp02.au.ibm.com (Postfix) with ESMTP id DDEA42BB0054 for ; Thu, 28 Jan 2016 20:44:33 +1100 (EST) Received: from d23av02.au.ibm.com (d23av02.au.ibm.com [9.190.235.138]) by d23relay07.au.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id u0S9iRqV12124372 for ; Thu, 28 Jan 2016 20:44:35 +1100 Received: from d23av02.au.ibm.com (localhost [127.0.0.1]) by d23av02.au.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id u0S9i08l005912 for ; Thu, 28 Jan 2016 20:44:01 +1100 From: "Aneesh Kumar K.V" Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit In-Reply-To: References: <87k2n2usyf.fsf@linux.vnet.ibm.com> <20160122163801.GA16668@cmpxchg.org> Date: Thu, 28 Jan 2016 15:13:33 +0530 Message-ID: <877fiu59a2.fsf@linux.vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain Sender: owner-linux-mm@kvack.org List-ID: To: Joonsoo Kim , Johannes Weiner Cc: lsf-pc@lists.linux-foundation.org, Linux Memory Management List , Joonsoo Kim , Peter Zijlstra Joonsoo Kim writes: > Hello, > > 2016-01-23 1:38 GMT+09:00 Johannes Weiner : >> Hi, >> >> On Fri, Jan 22, 2016 at 10:11:12AM +0530, Aneesh Kumar K.V wrote: >>> * CMA allocator issues: >>> (1) order zero allocation failures: >>> We are observing order zero non-movable allocation failures in kernel >>> with CMA configured. We don't start a reclaim because our free memory check >>> does not consider free_cma. Hence the reclaim code assume we have enough free >>> pages. Joonsoo Kim tried to fix this with his ZOME_CMA patches. I would >>> like to discuss the challenges in getting this merged upstream. >>> https://lkml.org/lkml/2015/2/12/95 (ZONE_CMA) > > As far as I know, there is no disagreement on this patchset in last year LSF/MM. > Problem may be due to my laziness... Sorry about that. I will handle it soon. > Is there anything more that you concern? > >> The exclusion of cma pages from the watermark checks means that >> reclaim is happening too early, not too late, which leaves memory >> underutilized. That's what ZONE_CMA set out to fix. >> >> But unmovable allocations can still fail when the only free memory is >> inside CMA regions. I don't see how ZONE_CMA would fix that. >> >> CC Joonsoo > > I understand what Aneesh's problem is. > > Assume that > > X = non movable free page > Y = movable free page > Z = cma free page > > X < min watermark > X + Y > high watermark > Z > high watermark > > If there are bunch of consecutive movable allocation requests, > Y will decrease. After some time, Y will be exhausted. At that > time, there is enough Z so movable allocation request still can be > handled in fastpath and kswapd isn't waked up. In that situation, > if atomic non-movable page allocation for order-0 comes, > it would be failed. > > Although it isn't mentioned on ZONE_CMA patchset, it is also > fixed by that patchset because with that patchset, all CMA pages > are in CMA zone so freepage calculation is always precise. > That is the issue I am hitting and if we don't have any blocker against ZONE_CMA then we can drop this topic. -aneesh -- 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: email@kvack.org From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755651AbcAOIK6 (ORCPT ); Fri, 15 Jan 2016 03:10:58 -0500 Received: from mx1.redhat.com ([209.132.183.28]:44699 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755031AbcAOIK5 (ORCPT ); Fri, 15 Jan 2016 03:10:57 -0500 Date: Fri, 15 Jan 2016 09:10:51 +0100 From: Jesper Dangaard Brouer To: "Martin K. Petersen" , lsf-pc@lists.linux-foundation.org Cc: brouer@redhat.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, Christoph Lameter Subject: [LSF/MM ATTEND] 2016: Requests to attend MM-summit Message-ID: <20160115091051.03715530@redhat.com> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 12 Jan 2016 11:05:45 -0500 "Martin K. Petersen" wrote: > The annual Linux Storage, Filesystem and Memory Management Summit for > 2016 will be held on April 18th and 19th at the Raleigh Marriott City > center, Raleigh, NC. > [...] > > 2) Requests to attend the summit should be sent to: > > lsf-pc@lists.linux-foundation.org > > Please summarise what expertise you will bring to the meeting, and what > you would like to discuss. Please also tag your email with [LSF/MM > ATTEND] so there is less chance of it getting lost. Hi committee, I would like to participate in LSF/MM. I've over the last year optimized the SLAB+SLUB allocators, specifically by introducing a bulking API. This work is almost complete, but I have some more ideas in the MM-area that I would like to discuss with people. Specifically I have the following ideas: 1. Speedup *SLUB* with approx 10-20% by using per CPU detached freelists for all types of allocations/free. * Actually have a prove-of-concept implementation that showed 20% speedup * Idea is every page (used-by SLUB) gets a detached freelist * The first CPU that alloc the page, owns this detached freelist * CPU owning page can do sync free operation on this freelist. * SLUB is already highly biased to keep objects on same CPU 2. Bulk alloc without disabling IRQ (SLUB) * This is something Real-Time (RT) people will be screaming for, once more users of bulk API starts to appear. * I think it is doable, but also very challenging to keep performance 3. Faster memset clearing of memory in SLUB * Currently netstack clears SKBs right after alloc (2-3% in perf) * In SLUB allocator we could clear larger section of memory which is significantly faster. * Bulk alloc would be the right spot * Difficult part is inventing an algorithm for matching contiguous mem, which is fast-enough, as the est. time budget is 15-20 cycles. 4. Bulk free from RCU context * One major slowdown of using RCU free is, that free will always hit SLUB slowpath. We could change this via bulk free API. * This would be a major benefit for the entire kernel performance. * The challenge here is getting to know the RCU free code well-enough -- Best regards, Jesper Dangaard Brouer MSc.CS, Principal Kernel Engineer at Red Hat Author of http://www.iptv-analyzer.org LinkedIn: http://www.linkedin.com/in/brouer From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754621AbcAOQtg (ORCPT ); Fri, 15 Jan 2016 11:49:36 -0500 Received: from resqmta-ch2-06v.sys.comcast.net ([69.252.207.38]:52429 "EHLO resqmta-ch2-06v.sys.comcast.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751464AbcAOQte (ORCPT ); Fri, 15 Jan 2016 11:49:34 -0500 Date: Fri, 15 Jan 2016 10:49:33 -0600 (CST) From: Christoph Lameter X-X-Sender: cl@east.gentwo.org To: Jesper Dangaard Brouer cc: "Martin K. Petersen" , lsf-pc@lists.linux-foundation.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org Subject: Re: [LSF/MM ATTEND] 2016: Requests to attend MM-summit In-Reply-To: <20160115091051.03715530@redhat.com> Message-ID: References: <20160115091051.03715530@redhat.com> Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, 15 Jan 2016, Jesper Dangaard Brouer wrote: > I've over the last year optimized the SLAB+SLUB allocators, > specifically by introducing a bulking API. This work is almost > complete, but I have some more ideas in the MM-area that I would like > to discuss with people. I think this is pretty good work which can help a lot for subsystems dealing with large amounts of objects. Given that network speeds and memory increases we may have to look increasingly at bulk allocation to make further strides in MM performance by rewriting subsystems to take advantage of these features.