From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andreas Dilger Subject: Re: [RFC] quota: 64-bit limits with vfs Date: Sat, 15 Mar 2008 22:45:06 +0800 Message-ID: <20080315144506.GT3542@webber.adilger.int> References: <200803061641.12274.andrew.perepechko@sun.com> <200803141608.10761.andrew.perepechko@sun.com> <20080315042316.GP3542@webber.adilger.int> <200803151624.02791.andrew.perepechko@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT Cc: Jan Kara , linux-fsdevel@vger.kernel.org, Johann Lombardi , Zhiyong Landen tian , Alex Lyashkov To: Andrew Perepechko Return-path: Received: from sca-es-mail-2.Sun.COM ([192.18.43.133]:62656 "EHLO sca-es-mail-2.sun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751780AbYCOOpl (ORCPT ); Sat, 15 Mar 2008 10:45:41 -0400 Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id m2FEjehD000571 for ; Sat, 15 Mar 2008 07:45:40 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JXS00B010XBUA00@fe-sfbay-10.sun.com> (original mail from adilger@sun.com) for linux-fsdevel@vger.kernel.org; Sat, 15 Mar 2008 07:45:39 -0700 (PDT) In-reply-to: <200803151624.02791.andrew.perepechko@sun.com> Content-disposition: inline Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Mar 15, 2008 16:24 +0300, Andrew Perepechko wrote: > On Saturday 15 March 2008 07:23:16 Andreas Dilger wrote: > > In a few places you add new on-stack variables like "sb", but they aren't > > used more than 1 or 2 times. While it makes the code a tiny bit clearer > > (though not largely so for "sb" because it is only dquot->dq_sb) it does > > increase the stack usage, and that is never a good idea. > > I agree. Probably, it makes sense to rollback sb change. Though this may lead > to additional line breaks. Line breaks don't consume stack space ;-). > > Hmm, allocating "fakedquot" on the stack just to compare it to zero > > doesn't seem like a good use of space. What about doing the memcmp() > > against page_address(ZERO_PAGE(0))? It might be nice to have a permanent > > mapping of ZERO_PAGE(0) like void *zero_buffer that can be used for this. > > What do you think about something like this? > > +static union v2_disk_dqblk emptydquot; > +static union v2_disk_dqblk fakedquot[2] = { > + {.disk_dqblk_r0 = {.dqb_itime = __constant_cpu_to_le64(1LLU)}}, > + {.disk_dqblk_r1 = {.dqb_itime = __constant_cpu_to_le64(1LLU)}} > +}; Yes, since these structures are constant there are no multi-thread issues. Not only does this use less stack space, but it is better performing as well due to less memset() overhead. NB - it seems you have whitespace at the end of some lines, please remove it. >@@ -724,9 +724,7 @@ static int v2_read_dquot(struct dquot *d > else { > ret = 0; > /* We need to escape back all-zero structure */ >- memset(&empty, 0, dqblksz); >- DQF_PUT(&empty, rev, dqb_itime, 1); >- if (!memcmp(&empty, &ddquot, dqblksz)) >+ if (!memcmp(&fakedquot[rev], &ddquot, dqblksz)) > DQF_PUT(&ddquot, rev, dqb_itime, 0); > } I wonder if there is a CPU instruction "compare memory with zero" that would be available for something like this, that could be used like: if (!memzcmp(&ddquot, dqblksz)) DQF_PUT(&ddquot, rev, dqb_itime, 0); I know I've had to use a few hacks like this to check if some buffer is zero filled, so having it efficiently done by the CPU would be a win. It would be possible to use something like generic_find_first_bit(): #define memzcmp(ptr, bytes) (generic_find_first_bit(ptr, bytes*8) >= bytes*8) which breaks down to an assembly instruction "bsfq" on x86_64 if the parameter is constant. That might make it more efficient to have 2 separate codepaths here with a constant "bytes" parameter so that the larger memzcmp() can be optimized. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc.