Return-Path: Received: from mail-lb0-f172.google.com ([209.85.217.172]:36582 "EHLO mail-lb0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1032148AbbKELHH (ORCPT ); Thu, 5 Nov 2015 06:07:07 -0500 Received: by lbblt2 with SMTP id lt2so13714986lbb.3 for ; Thu, 05 Nov 2015 03:07:05 -0800 (PST) MIME-Version: 1.0 In-Reply-To: References: <1446563847-14005-1-git-send-email-agruenba@redhat.com> <1446563847-14005-46-git-send-email-agruenba@redhat.com> Date: Thu, 5 Nov 2015 12:07:05 +0100 Message-ID: Subject: Re: [PATCH v13 45/51] sunrpc: Allow to demand-allocate pages to encode into From: Andreas Gruenbacher To: Trond Myklebust Cc: Alexander Viro , "Theodore Ts'o" , Andreas Dilger , "J. Bruce Fields" , Jeff Layton , Anna Schumaker , Dave Chinner , linux-ext4 , XFS Developers , Linux Kernel Mailing List , Linux FS-devel Mailing List , Linux NFS Mailing List , linux-cifs@vger.kernel.org, Linux API Mailing List Content-Type: text/plain; charset=UTF-8 Sender: linux-nfs-owner@vger.kernel.org List-ID: Trond, On Tue, Nov 3, 2015 at 5:25 PM, Trond Myklebust wrote: > On Tue, Nov 3, 2015 at 10:17 AM, Andreas Gruenbacher > wrote: >> When encoding large, variable-length objects such as acls into xdr_bufs, >> it is easier to allocate buffer pages on demand rather than precomputing >> the required buffer size. > > NACK. We're not doing allocations from inside the XDR encoders. This > can and should be done before calling into the SUNRPC layer. an XDR-encoded ACL can be up to 64k (16 pages) in size. In practice, large ACLs like that will almost never occur and almost all ACLs will fit into a single page though. The XDR-encoded ACL contains strings for the user and group names which need to be looked up when the idmapper is used. Those lookups are somewhat expensive; in addition, the lookup results can change over time. When precomputing the size, allocating space, and then encoding the ACL, we could run out of space when encoding. So we could always allocate the maximum 16 pages, encode the acl, and free the unused pages. This would be rather wasteful though. Given how simple it is to allocate pages as we go, this seems the better choice here. This doesn't break any existing code either; NULL page pointers would have oopsed in xdr_get_next_encode_buffer before.