From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it1-f195.google.com ([209.85.166.195]:38599 "EHLO mail-it1-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725749AbeLAJWr (ORCPT ); Sat, 1 Dec 2018 04:22:47 -0500 Received: by mail-it1-f195.google.com with SMTP id h65so727207ith.3 for ; Fri, 30 Nov 2018 14:12:01 -0800 (PST) Subject: Re: [PATCH 27/27] aio: add support for pre-mapped user IO buffers To: Jeff Moyer Cc: linux-block@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-aio@kvack.org, hch@lst.de References: <20181130165646.27341-1-axboe@kernel.dk> <20181130165646.27341-28-axboe@kernel.dk> <8dc2ea1d-b6a4-728b-7550-87d32240989c@kernel.dk> From: Jens Axboe Message-ID: Date: Fri, 30 Nov 2018 15:11:59 -0700 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 11/30/18 3:04 PM, Jeff Moyer wrote: > Jens Axboe writes: > >>>> A limit of 4M is imposed as the largest buffer we currently support. >>>> There's nothing preventing us from going larger, but we need some cap, >>>> and 4M seemed like it would definitely be big enough. >>> >>> Doesn't this mean that a user can pin a bunch of memory? Something like >>> 4MB * aio_max_nr? >>> >>> $ sysctl fs.aio-max-nr >>> fs.aio-max-nr = 1048576 >>> >>> If so, it may be a good idea to account the memory under RLIMIT_MEMLOCK. >> >> Yes, it'll need some kind of limiting, right now the limit would indeed >> be aio-max-nr * 4MB. 4G isn't terrible, but... > > Unless my math's wrong, that's 4TiB on my system. ;-) I guess that's a little more terrible ;-) >> RLIMIT_MEMLOCK isn't a bad idea. >> >>> I'm not sure how close you are to proposing this patch set for realz. >>> If it's soon (now?), then CC-ing linux-api and writing man pages would >>> be a good idea. I can help out with the libaio bits if you'd like. I >>> haven't yet had time to take this stuff for a spin, sorry. I'll try to >>> get to that soonish. >> >> I am proposing it for real, not sure how long it'll take to get it >> reviewed and moved forward. Unless I get lucky. 4.22 seems like a more >> viable version than 4.21. >> >> I'll take any help I can get on the API/man page parts. And/or testing! > > OK, I'll add libaio support (including unit tests), write the man page, > and I'll definitely do some testing. I'll start on all that probably in > the latter half of next week. Awesome, that's much appreciated! -- Jens Axboe