From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-yk0-f173.google.com (mail-yk0-f173.google.com [209.85.160.173]) by kanga.kvack.org (Postfix) with ESMTP id 8B5776B0038 for ; Thu, 12 Nov 2015 15:55:36 -0500 (EST) Received: by ykfs79 with SMTP id s79so113939297ykf.1 for ; Thu, 12 Nov 2015 12:55:36 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id v5si10924483ywb.119.2015.11.12.12.55.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 12 Nov 2015 12:55:35 -0800 (PST) Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) by mx1.redhat.com (Postfix) with ESMTPS id 200EB8F506 for ; Thu, 12 Nov 2015 20:55:35 +0000 (UTC) Date: Thu, 12 Nov 2015 21:55:31 +0100 From: Jesper Dangaard Brouer Subject: Memory exhaustion testing? Message-ID: <20151112215531.69ccec19@redhat.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: linux-mm Cc: brouer@redhat.com Hi MM-people, How do you/we test the error paths when the system runs out of memory? What kind of tools do you use? or Any tricks to provoke this? For testing my recent change to the SLUB allocator, I've implemented a crude kernel module that tries to allocate all memory, so I can test the error code-path in kmem_cache_alloc_bulk. see: https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test04_exhaust_mem.c -- 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-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by kanga.kvack.org (Postfix) with ESMTP id 212D86B0038 for ; Fri, 13 Nov 2015 17:54:40 -0500 (EST) Received: by pacej9 with SMTP id ej9so6272842pac.2 for ; Fri, 13 Nov 2015 14:54:39 -0800 (PST) Received: from mail-pa0-x231.google.com (mail-pa0-x231.google.com. [2607:f8b0:400e:c03::231]) by mx.google.com with ESMTPS id ia2si30190237pbb.85.2015.11.13.14.54.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 13 Nov 2015 14:54:39 -0800 (PST) Received: by pacej9 with SMTP id ej9so6272695pac.2 for ; Fri, 13 Nov 2015 14:54:39 -0800 (PST) Date: Fri, 13 Nov 2015 14:54:37 -0800 (PST) From: David Rientjes Subject: Re: Memory exhaustion testing? In-Reply-To: <20151112215531.69ccec19@redhat.com> Message-ID: References: <20151112215531.69ccec19@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Jesper Dangaard Brouer Cc: linux-mm On Thu, 12 Nov 2015, Jesper Dangaard Brouer wrote: > Hi MM-people, > > How do you/we test the error paths when the system runs out of memory? > > What kind of tools do you use? > or Any tricks to provoke this? > Depends on the paths that you want to exercise when the system is out of memory :) If it's just to trigger the oom killer, then no kernel module should be necessary if you're not limited by any cgroup and just disable swap and start off an anonymous memory hog that consumes all memory. > For testing my recent change to the SLUB allocator, I've implemented a > crude kernel module that tries to allocate all memory, so I can test the > error code-path in kmem_cache_alloc_bulk. > Trying to exercise certain paths under oom is difficult because the oom killer will usually quickly kill a process or you'll get hung up somewhere else that needs memory before the function you want to test. This is why failslab had been used in the past, and does a good job at runtime testing. My suggestion would just be to instrument the kernel to randomly fail as though the system is oom and ensure that it works. -- 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-f54.google.com (mail-pa0-f54.google.com [209.85.220.54]) by kanga.kvack.org (Postfix) with ESMTP id 7C1496B0038 for ; Sat, 14 Nov 2015 03:23:28 -0500 (EST) Received: by padhx2 with SMTP id hx2so123225554pad.1 for ; Sat, 14 Nov 2015 00:23:28 -0800 (PST) Received: from www262.sakura.ne.jp (www262.sakura.ne.jp. [2001:e42:101:1:202:181:97:72]) by mx.google.com with ESMTPS id sc1si33541849pbb.21.2015.11.14.00.23.26 for (version=TLS1 cipher=AES128-SHA bits=128/128); Sat, 14 Nov 2015 00:23:27 -0800 (PST) Subject: Re: Memory exhaustion testing? References: <20151112215531.69ccec19@redhat.com> From: Tetsuo Handa Message-ID: <5646EF73.5010005@I-love.SAKURA.ne.jp> Date: Sat, 14 Nov 2015 17:23:15 +0900 MIME-Version: 1.0 In-Reply-To: <20151112215531.69ccec19@redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Jesper Dangaard Brouer , linux-mm On 2015/11/13 5:55, Jesper Dangaard Brouer wrote: > Hi MM-people, > > How do you/we test the error paths when the system runs out of memory? > > What kind of tools do you use? > or Any tricks to provoke this? I use SystemTap for injecting memory allocation failure. http://lkml.kernel.org/r/201503182136.EJC90660.QSFOVJFOLHFOtM@I-love.SAKURA.ne.jp > > For testing my recent change to the SLUB allocator, I've implemented a > crude kernel module that tries to allocate all memory, so I can test the > error code-path in kmem_cache_alloc_bulk. > > see: > https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test04_exhaust_mem.c > I think you can test the error code-path in kmem_cache_alloc_bulk as well. -- 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-yk0-f175.google.com (mail-yk0-f175.google.com [209.85.160.175]) by kanga.kvack.org (Postfix) with ESMTP id D6F806B0254 for ; Mon, 16 Nov 2015 09:24:45 -0500 (EST) Received: by ykfs79 with SMTP id s79so241356953ykf.1 for ; Mon, 16 Nov 2015 06:24:45 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id l139si23392366ywb.93.2015.11.16.06.24.44 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 06:24:45 -0800 (PST) Date: Mon, 16 Nov 2015 15:24:40 +0100 From: Jesper Dangaard Brouer Subject: Re: Memory exhaustion testing? Message-ID: <20151116152440.101ea77d@redhat.com> In-Reply-To: References: <20151112215531.69ccec19@redhat.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: David Rientjes Cc: linux-mm , brouer@redhat.com, Tetsuo Handa On Fri, 13 Nov 2015 14:54:37 -0800 (PST) David Rientjes wrote: > [...] This is why > failslab had been used in the past, and does a good job at runtime > testing. Thanks for mentioning CONFIG_FAILSLAB. First I disregarded "failslab" (I did notice it in the slub code) because it didn't exercised the code path I wanted in kmem_cache_alloc_bulk(). But went to looking up the config setting I notice that we do have a hole section for "Fault-injection". Which is great, and what I was looking for. Menu config Location: -> Kernel hacking -> Fault-injection framework (FAULT_INJECTION [=y]) I think what I need can be covered by FAIL_PAGE_ALLOC, or should_fail_alloc_page(). I'll try and play a bit with it... - - 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 [*] Fault-injection framework [*] Fault-injection capability for kmalloc [*] Fault-injection capabilitiy for alloc_pages() [ ] Fault-injection capability for disk IO [ ] Fault-injection capability for faking disk interrupts [ ] Fault-injection capability for futexes [*] Debugfs entries for fault-injection capabilities -- 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-yk0-f182.google.com (mail-yk0-f182.google.com [209.85.160.182]) by kanga.kvack.org (Postfix) with ESMTP id 366086B0255 for ; Mon, 16 Nov 2015 09:43:37 -0500 (EST) Received: by ykdr82 with SMTP id r82so241211447ykd.3 for ; Mon, 16 Nov 2015 06:43:37 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id y136si23505687ywd.16.2015.11.16.06.43.36 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 16 Nov 2015 06:43:36 -0800 (PST) Date: Mon, 16 Nov 2015 15:43:32 +0100 From: Jesper Dangaard Brouer Subject: Re: Memory exhaustion testing? Message-ID: <20151116154332.3f8fd151@redhat.com> In-Reply-To: <5646EF73.5010005@I-love.SAKURA.ne.jp> References: <20151112215531.69ccec19@redhat.com> <5646EF73.5010005@I-love.SAKURA.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: Tetsuo Handa Cc: linux-mm , brouer@redhat.com On Sat, 14 Nov 2015 17:23:15 +0900 Tetsuo Handa wrote: > On 2015/11/13 5:55, Jesper Dangaard Brouer wrote: > > Hi MM-people, > > > > How do you/we test the error paths when the system runs out of memory? > > > > What kind of tools do you use? > > or Any tricks to provoke this? > > I use SystemTap for injecting memory allocation failure. > > http://lkml.kernel.org/r/201503182136.EJC90660.QSFOVJFOLHFOtM@I-love.SAKURA.ne.jp > > > > > For testing my recent change to the SLUB allocator, I've implemented a > > crude kernel module that tries to allocate all memory, so I can test the > > error code-path in kmem_cache_alloc_bulk. > > > > see: > > https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test04_exhaust_mem.c > > > > I think you can test the error code-path in kmem_cache_alloc_bulk as > well. Yes, making __alloc_pages_nodemask() fail should propagate all the way back into kmem_cache_alloc_bulk(). I do like your approach, but I think my use-case can be covered by CONFIG_FAIL_PAGE_ALLOC (which like you, also hook into __alloc_pages_nodemask). Although it seems I have more control with your approach, to filter in which situations it should happen in. Thanks for your input! :-) -- 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-vk0-f46.google.com (mail-vk0-f46.google.com [209.85.213.46]) by kanga.kvack.org (Postfix) with ESMTP id E3ACD6B0257 for ; Tue, 17 Nov 2015 08:21:25 -0500 (EST) Received: by vkha189 with SMTP id a189so4927399vkh.1 for ; Tue, 17 Nov 2015 05:21:25 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id x145si2640482vke.199.2015.11.17.05.21.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 Nov 2015 05:21:24 -0800 (PST) Date: Tue, 17 Nov 2015 14:21:20 +0100 From: Jesper Dangaard Brouer Subject: Re: Memory exhaustion testing? Message-ID: <20151117142120.494947f9@redhat.com> In-Reply-To: <20151116152440.101ea77d@redhat.com> References: <20151112215531.69ccec19@redhat.com> <20151116152440.101ea77d@redhat.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: David Rientjes Cc: linux-mm , Tetsuo Handa , brouer@redhat.com On Mon, 16 Nov 2015 15:24:40 +0100 Jesper Dangaard Brouer wrote: > On Fri, 13 Nov 2015 14:54:37 -0800 (PST) David Rientjes wrote: > > > [...] This is why > > failslab had been used in the past, and does a good job at runtime > > testing. > > Thanks for mentioning CONFIG_FAILSLAB. First I disregarded > "failslab" (I did notice it in the slub code) because it didn't > exercised the code path I wanted in kmem_cache_alloc_bulk(). > > But went to looking up the config setting I notice that we do have a > hole section for "Fault-injection". Which is great, and what I was > looking for. > > Menu config Location: > -> Kernel hacking > -> Fault-injection framework (FAULT_INJECTION [=y]) > > I think what I need can be covered by FAIL_PAGE_ALLOC, or should_fail_alloc_page(). > I'll try and play a bit with it... I did manage to provoke/test the error path in kmem_cache_alloc_bulk(), by using fault-injection framework "fail_page_alloc". But was a little hard to trigger SLUB errors with this, because SLUB retries after a failure, and second call to alloc_pages() is done with lower order. If order is lowered to zero, then should_fail_alloc_page() will skip it. And just lowering /sys/kernel/debug/fail_page_alloc/min-order=0 is not feasible as even fork starts to fail. I managed to work-around this by using "space" setting. Created a script to ease this tricky invocation: https://github.com/netoptimizer/prototype-kernel/blob/master/tests/fault-inject/fail01_kmem_cache_alloc_bulk.sh -- 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-pa0-f53.google.com (mail-pa0-f53.google.com [209.85.220.53]) by kanga.kvack.org (Postfix) with ESMTP id AEAA76B0253 for ; Thu, 19 Nov 2015 15:40:53 -0500 (EST) Received: by padhx2 with SMTP id hx2so91752273pad.1 for ; Thu, 19 Nov 2015 12:40:53 -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 sv10si656087pab.134.2015.11.19.12.40.52 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 19 Nov 2015 12:40:52 -0800 (PST) Received: by pacdm15 with SMTP id dm15so91768133pac.3 for ; Thu, 19 Nov 2015 12:40:52 -0800 (PST) Date: Thu, 19 Nov 2015 12:40:50 -0800 (PST) From: David Rientjes Subject: Re: Memory exhaustion testing? In-Reply-To: <20151117142120.494947f9@redhat.com> Message-ID: References: <20151112215531.69ccec19@redhat.com> <20151116152440.101ea77d@redhat.com> <20151117142120.494947f9@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Jesper Dangaard Brouer Cc: linux-mm , Tetsuo Handa On Tue, 17 Nov 2015, Jesper Dangaard Brouer wrote: > I did manage to provoke/test the error path in kmem_cache_alloc_bulk(), > by using fault-injection framework "fail_page_alloc". > > But was a little hard to trigger SLUB errors with this, because SLUB > retries after a failure, and second call to alloc_pages() is done with > lower order. > > If order is lowered to zero, then should_fail_alloc_page() will skip it. > And just lowering /sys/kernel/debug/fail_page_alloc/min-order=0 is not > feasible as even fork starts to fail. I managed to work-around this by > using "space" setting. > > Created a script to ease this tricky invocation: > https://github.com/netoptimizer/prototype-kernel/blob/master/tests/fault-inject/fail01_kmem_cache_alloc_bulk.sh > Any chance you could proffer some of your scripts in the form of patches to the tools/testing directory? Anything that can reliably trigger rarely executed code is always useful. -- 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-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by kanga.kvack.org (Postfix) with ESMTP id 6C9186B0253 for ; Fri, 20 Nov 2015 08:09:22 -0500 (EST) Received: by obbnk6 with SMTP id nk6so85646310obb.2 for ; Fri, 20 Nov 2015 05:09:22 -0800 (PST) Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28]) by mx.google.com with ESMTPS id w8si9643316obo.67.2015.11.20.05.09.21 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 05:09:21 -0800 (PST) Date: Fri, 20 Nov 2015 14:09:16 +0100 From: Jesper Dangaard Brouer Subject: Re: Memory exhaustion testing? Message-ID: <20151120140916.33ec7896@redhat.com> In-Reply-To: References: <20151112215531.69ccec19@redhat.com> <20151116152440.101ea77d@redhat.com> <20151117142120.494947f9@redhat.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: David Rientjes Cc: linux-mm , Tetsuo Handa , brouer@redhat.com On Thu, 19 Nov 2015 12:40:50 -0800 (PST) David Rientjes wrote: > On Tue, 17 Nov 2015, Jesper Dangaard Brouer wrote: > > > I did manage to provoke/test the error path in kmem_cache_alloc_bulk(), > > by using fault-injection framework "fail_page_alloc". > > > > But was a little hard to trigger SLUB errors with this, because SLUB > > retries after a failure, and second call to alloc_pages() is done with > > lower order. > > > > If order is lowered to zero, then should_fail_alloc_page() will skip it. > > And just lowering /sys/kernel/debug/fail_page_alloc/min-order=0 is not > > feasible as even fork starts to fail. I managed to work-around this by > > using "space" setting. > > > > Created a script to ease this tricky invocation: > > https://github.com/netoptimizer/prototype-kernel/blob/master/tests/fault-inject/fail01_kmem_cache_alloc_bulk.sh > > > > Any chance you could proffer some of your scripts in the form of patches > to the tools/testing directory? Anything that can reliably trigger rarely > executed code is always useful. Perhaps that is a good idea. I think should move the directory location in my git-repo prototype-kernel[1] to reflect this directory layout, like I do with real kernel stuff. And when we are happy with the quality of the scripts we can "move" it to the kernel. (Like I did with my pktgen tests[4], now located in samples/pktgen/). A question; where should/could we place the kernel module slab_bulk_test04_exhaust_mem[1] that my fail01 script depends on? BTW, I've also added a script for testing NULL handling in normal kmem_cache_alloc() call see[3]. -- 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 [1] https://github.com/netoptimizer/prototype-kernel/ [2] https://github.com/netoptimizer/prototype-kernel/blob/master/kernel/mm/slab_bulk_test04_exhaust_mem.c [3] https://github.com/netoptimizer/prototype-kernel/blob/master/tests/fault-inject/fail02_kmem_cache_alloc.sh [4] https://github.com/netoptimizer/network-testing/tree/master/pktgen -- 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-f47.google.com (mail-pa0-f47.google.com [209.85.220.47]) by kanga.kvack.org (Postfix) with ESMTP id 37D036B0038 for ; Fri, 20 Nov 2015 18:23:12 -0500 (EST) Received: by pacdm15 with SMTP id dm15so129973705pac.3 for ; Fri, 20 Nov 2015 15:23:12 -0800 (PST) Received: from mail-pa0-x236.google.com (mail-pa0-x236.google.com. [2607:f8b0:400e:c03::236]) by mx.google.com with ESMTPS id hu9si2242453pbc.87.2015.11.20.15.23.11 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 15:23:11 -0800 (PST) Received: by padhx2 with SMTP id hx2so130013306pad.1 for ; Fri, 20 Nov 2015 15:23:11 -0800 (PST) Date: Fri, 20 Nov 2015 15:23:09 -0800 (PST) From: David Rientjes Subject: Re: Memory exhaustion testing? In-Reply-To: <20151120140916.33ec7896@redhat.com> Message-ID: References: <20151112215531.69ccec19@redhat.com> <20151116152440.101ea77d@redhat.com> <20151117142120.494947f9@redhat.com> <20151120140916.33ec7896@redhat.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org List-ID: To: Andrew Morton , Jesper Dangaard Brouer Cc: linux-mm , Tetsuo Handa On Fri, 20 Nov 2015, Jesper Dangaard Brouer wrote: > > Any chance you could proffer some of your scripts in the form of patches > > to the tools/testing directory? Anything that can reliably trigger rarely > > executed code is always useful. > > Perhaps that is a good idea. > > I think should move the directory location in my git-repo > prototype-kernel[1] to reflect this directory layout, like I do with > real kernel stuff. And when we are happy with the quality of the > scripts we can "move" it to the kernel. (Like I did with my pktgen > tests[4], now located in samples/pktgen/). > > A question; where should/could we place the kernel module > slab_bulk_test04_exhaust_mem[1] that my fail01 script depends on? > I've had the same question because I'd like to add slab and page allocator benchmark modules originally developed by Christoph Lameter to the tree. Let's add Andrew. -- 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-f45.google.com (mail-wm0-f45.google.com [74.125.82.45]) by kanga.kvack.org (Postfix) with ESMTP id AF76B6B0255 for ; Fri, 20 Nov 2015 18:28:20 -0500 (EST) Received: by wmww144 with SMTP id w144so39672976wmw.0 for ; Fri, 20 Nov 2015 15:28:20 -0800 (PST) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org. [140.211.169.12]) by mx.google.com with ESMTPS id g2si2777655wjw.4.2015.11.20.15.28.19 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 20 Nov 2015 15:28:19 -0800 (PST) Date: Fri, 20 Nov 2015 15:28:17 -0800 From: Andrew Morton Subject: Re: Memory exhaustion testing? Message-Id: <20151120152817.388f3faf99bf657b9ae5ab30@linux-foundation.org> In-Reply-To: References: <20151112215531.69ccec19@redhat.com> <20151116152440.101ea77d@redhat.com> <20151117142120.494947f9@redhat.com> <20151120140916.33ec7896@redhat.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: David Rientjes Cc: Jesper Dangaard Brouer , linux-mm , Tetsuo Handa On Fri, 20 Nov 2015 15:23:09 -0800 (PST) David Rientjes wrote: > On Fri, 20 Nov 2015, Jesper Dangaard Brouer wrote: > > > > Any chance you could proffer some of your scripts in the form of patches > > > to the tools/testing directory? Anything that can reliably trigger rarely > > > executed code is always useful. > > > > Perhaps that is a good idea. > > > > I think should move the directory location in my git-repo > > prototype-kernel[1] to reflect this directory layout, like I do with > > real kernel stuff. And when we are happy with the quality of the > > scripts we can "move" it to the kernel. (Like I did with my pktgen > > tests[4], now located in samples/pktgen/). > > > > A question; where should/could we place the kernel module > > slab_bulk_test04_exhaust_mem[1] that my fail01 script depends on? > > > > I've had the same question because I'd like to add slab and page allocator > benchmark modules originally developed by Christoph Lameter to the tree. > Let's add Andrew. Well, fwiw the current approach is to build the testing module in lib/ (ls -l lib/*test*.c) and to modprobe it from selftests (grep -r modprobe tools/testing/selftests). Does that suit? I guess we could build and install a module from mm/ if that's needed for some reason. -- 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