From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jens Axboe Subject: Re: [patch] pipe: add support for shrinking and growing pipes Date: Thu, 3 Jun 2010 09:01:26 +0200 Message-ID: <20100603070126.GJ3564@kernel.dk> References: <20100524070552.GR23411@kernel.dk> <20100524173551.GU23411@kernel.dk> <20100524175649.GV23411@kernel.dk> <20100601074534.GL1660@kernel.dk> <20100603061039.GD3564@kernel.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: OGAWA Hirofumi , Andrew Morton , Linus Torvalds , Miklos Szeredi , "linux-fsdevel@vger.kernel.org" , "linux-kernel@vger.kernel.org" To: "mtk.manpages@gmail.com" Return-path: Received: from 0122700014.0.fullrate.dk ([95.166.99.235]:57538 "EHLO kernel.dk" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752148Ab0FCHB2 (ORCPT ); Thu, 3 Jun 2010 03:01:28 -0400 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jun 03 2010, Michael Kerrisk wrote: > Hi Jens, >=20 > On Thu, Jun 3, 2010 at 8:10 AM, Jens Axboe wrot= e: > > On Wed, Jun 02 2010, Michael Kerrisk wrote: > >> On Tue, Jun 1, 2010 at 9:45 AM, Jens Axboe wrote= : > >> > On Thu, May 27 2010, Michael Kerrisk wrote: > >> >> Jens, > >> >> > >> >> On Mon, May 24, 2010 at 7:56 PM, Jens Axboe wrote: > >> >> > On Mon, May 24 2010, Michael Kerrisk wrote: > >> >> >> On Mon, May 24, 2010 at 7:35 PM, Jens Axboe wrote: > >> >> >> > On Mon, May 24 2010, Michael Kerrisk wrote: > >> >> >> >> > Right, that looks like a thinko. > >> >> >> >> > > >> >> >> >> > I'll submit a patch changing it to bytes and the agreed= API and fix this > >> >> >> >> > -Eerror. Thanks for your comments and suggestions! > >> >> >> >> > >> >> >> >> Thanks. And of course you are welcome. (Please CC linux-a= pi@vger on > >> >> >> >> this patche (and all patches that change the API/ABI.) > >> >> >> > > >> >> >> > The first change is this: > >> >> >> > > >> >> >> > http://git.kernel.dk/?p=3Dlinux-2.6-block.git;a=3Dcommit;h= =3D0191f8697bbdfefcd36e7b8dc3eeddfe82893e4b > >> >> >> > > >> >> >> > and the one dealing with the pages vs bytes API is this: > >> >> >> > > >> >> >> > http://git.kernel.dk/?p=3Dlinux-2.6-block.git;a=3Dcommit;h= =3Db9598db3401282bb27b4aef77e3eee12015f7f29 > >> >> >> > > >> >> >> > Not tested yet, will do so before sending in of course. > >> >> >> > >> >> >> Eyeballing it quickly, these changes look right. > >> >> > > >> >> > Good, thanks. > >> >> > > >> >> >> Do you have some test programs you can make available? > >> >> > > >> >> > Actually I don't, I test it by modifying fio's splice engine = to set/get > >> >> > the pipe size and test the resulting transfers. > >> >> > >> >> An afterthought. Do there not also need to be fixes to the /pro= c > >> >> interfaces. I don't think they were included in your revised pa= tches. > >> > > >> > I think the proc part can be sanely left in pages, since it's ju= st a > >> > memory limiter. > >> > >> I can't see any advantage to using two different units for these > >> closely related APIs, and it does seem like it could be a source o= f > >> confusion. Similar APIs that I can think of like RLIMIT_MEMLOCK an= d > >> shmget() SHMMAX that impose per-process memory-related limits use > >> bytes. Best to be consistent, don't you think? > > > > But they are different interfaces. =A0I think the 'pass in required= size, > > return actual size' where actual size is >=3D required size makes s= ense > > for the syscall part, but for an "admin" interface it is more logic= al to > > deal in pages. Perhaps that's just me and the average admin does no= t > > agree. So while it's just detail, it's also an interface so has som= e > > importance. And if there's consensus that bytes is a cleaner interf= ace > > on the proc side as well, then lets change it. >=20 > I'll add one more datapoint to those that I already mentioned. > RLIMIT_STACK and RLIMIT_DATA (getrlimit()) is also expressed in bytes= =2E >=20 > There was only one vaguely related limit that I could find that > measured things in pages. Consider these two System V shared memory > limits: >=20 > SHMMAX > This is the maximum size (in bytes) of a shared memory segment. >=20 > SHMALL > This is a system-wide limit on the total number of pages of shared me= mory. >=20 > But in a way this almost confirms my point. SHMMAX is a limit the > governs the behavior of individual processes (like your /proc file), > while SHMALL is a limit that governs the behavior of the system as a > whole. There is a (sort of) logic to using bytes for one and pages fo= r > the other. >=20 > I think that I've said all I need to say on the topic. I'm inclined t= o > think yours /proc file should use bytes, since it seems consistent > with other simialr APIs. Others may confirm, or someone else mught > have a different insight. I'll commit a patch to change it to bytes. > PS I hope you are going to set the lower limit for the /proc file to > 4096B (a page) (?). Yes, I think I'll do that as a separate patch up front. --=20 Jens Axboe -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel= " in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html