Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4983961imu; Tue, 29 Jan 2019 10:46:44 -0800 (PST) X-Google-Smtp-Source: ALg8bN56rPOTWsreOtYIlv3ClB1hGv7NoE/X8pK0YZAMHLzVmhxTFTif+rVv/ly6yl/EeqSnX3vl X-Received: by 2002:a17:902:7848:: with SMTP id e8mr27767373pln.100.1548787604396; Tue, 29 Jan 2019 10:46:44 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1548787604; cv=none; d=google.com; s=arc-20160816; b=wX0Anr2O+dRgDKAz5yYGjDFhmzbT1zVhkC7MJyW+O5W/OAYO0kHhl9LITB9O19d4Sn OJO8gCRzymY8A68zxv2b3oRPiDIjw6fpNQbzm+uEt4XRWzJYZqbXx2X5A2OCjfNLzOqN qgOCrwVvVRNT8McKYfbhg4xic2VyFMuUyTyJOMjr2zwwidW/HE+DJywiUGrm4AsKca38 qnwpHQZVfhSdJAipWxfzK55tWzov13yoPtNLx2U9lK7CMEHtb97M+rqxsUN62cBhghWG m6+OyPeGXIrqtHqmckH/jdN33F012PphncIZNjQYU4UPL7SFvU9dPLti3aqqaoNdk82Z 5Qtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=3HznCahcR9PJC4DfXzGXeZgIhzUTceviPpPfD0Lwqqg=; b=0mjSTDd5jKDURs7+I/Fq35bW7JIGo5eTucQnnDE/u0ivtw+EXgcvYJILSgFNKlBqlb /N9S2HIFeDQhn/OIYVVc6TNntaT12d2b0EdAR/PyhUizhvws0HssiiAZd7VfJRT0TYAt vXpiB+ZRtv4AvGE6xtbEHhArsVGKuvxjnzBBVuC288gSQmnOvRfaDoiKNDy5ZzC2oHwH r9evnMJDr6JwvNVuokidFKYqlPwGr9FP3Rwdqqg1nKTjqjSHCBdPOMw+K1UkqgWnsMVQ lS58ToijtwTv3JhrbA2PlRkxHbmkMCeYa0ogJyQJZgkvBCoH7HO7C1+4FWF+SR7wdUWD CY8w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=GBqCsC1K; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id p64si36566547pfg.79.2019.01.29.10.46.28; Tue, 29 Jan 2019 10:46:44 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=GBqCsC1K; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728971AbfA2Soa (ORCPT + 99 others); Tue, 29 Jan 2019 13:44:30 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:38369 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726846AbfA2Soa (ORCPT ); Tue, 29 Jan 2019 13:44:30 -0500 Received: by mail-qt1-f193.google.com with SMTP id p17so23432162qtl.5 for ; Tue, 29 Jan 2019 10:44:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=3HznCahcR9PJC4DfXzGXeZgIhzUTceviPpPfD0Lwqqg=; b=GBqCsC1Kkv1tH4l3FfUrLYKxSQi/1ZMoGK1QVrakqcnrzvoBgWpdCcWQv3SRR+DzyV 979pbeFgq3fad/EX9WL2MGpt34MvXUSDee+Joge0ORw7rbg/jpcJaOEy9pkYUoyuBiw6 SnuY618hW8XR/HZFG5uHwyLMIIfkuyE1udAfd77fTrp0nPh0YVfqkLqAeGRy8g0cSTJw A9gMIV0IN1fiOnVulShM8SyfLDoxXGQyoPBJ2szNhkE2OvEqFP+7GvNNS72DG/tswiMX sthbLfII+ln9/2MiyA3dU8+RwcqE/QR4ByeDTV9l0I4geGItOgPTg+kt7fPpIeerunVk 9afw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=3HznCahcR9PJC4DfXzGXeZgIhzUTceviPpPfD0Lwqqg=; b=ZEpp7UoH/O2k9p1vm+ScTCqeL8nTohe6HmzygOc+W3GN7pvvBW2qYk5BZKIeTIeZHj xl62vUpinB2EDMO3EeHnsVue7upKDwDVjTaabwY5DooATdieXqDJYGmJRvScBIYPP4bn CnHfQirvEgnrTuEeVQ5ePL6ihZRuxcb7aoxl6F3F+XBeKXoUSdAfpKdXNjB/TTry0ONB rA/NL8KLjojoZvvuqxQ81cx0ECwfRqaRcjHABKLdZaYJd1WSkzkRnSvTEwIidjBUZem+ eVbFoZ3WjnStHclgvqz9ot4SfNj2eGVFyu4Jo6sSJud8k9+Gey5sr1pLYLchDfGG2RRE lJ3Q== X-Gm-Message-State: AJcUukf6oQ21/azy1Ug2oAxJzVbbPvOPe37vFawdmcK4nKIL6ui4pjBg EWYcedIZe62f+6QoxEuBRYlTuA== X-Received: by 2002:a0c:fa46:: with SMTP id k6mr25062176qvo.36.1548787468744; Tue, 29 Jan 2019 10:44:28 -0800 (PST) Received: from localhost ([107.15.81.208]) by smtp.gmail.com with ESMTPSA id n72sm92516793qki.26.2019.01.29.10.44.27 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 29 Jan 2019 10:44:28 -0800 (PST) Date: Tue, 29 Jan 2019 13:44:26 -0500 From: Josef Bacik To: Josef Bacik Cc: Dennis Zhou , David Sterba , Chris Mason , Omar Sandoval , Nick Terrell , kernel-team@fb.com, linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 07/11] btrfs: move to fn pointers for get/put workspaces Message-ID: <20190129184425.itcwgyrvqdwfmzjx@MacBook-Pro-91.local> References: <20190128212437.11597-1-dennis@kernel.org> <20190128212437.11597-8-dennis@kernel.org> <20190129181716.hstuxkdzai4qiist@MacBook-Pro-91.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190129181716.hstuxkdzai4qiist@MacBook-Pro-91.local> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jan 29, 2019 at 01:17:17PM -0500, Josef Bacik wrote: > On Mon, Jan 28, 2019 at 04:24:33PM -0500, Dennis Zhou wrote: > > The previous patch added generic helpers for get_workspace() and > > put_workspace(). Now, we can migrate ownership of the workspace_manager > > to be in the compression type code as the compression code itself > > doesn't care beyond being able to get a workspace. The init/cleanup > > and get/put methods are abstracted so each compression algorithm can > > decide how they want to manage their workspaces. > > > > Signed-off-by: Dennis Zhou > > We're doing this to have special handling for extra workspaces to be free'd at > some point in the future if they are unused. This is fine by me, but why not > just add a shrinker and let it be handled by memory pressure? Then we avoid all > this abstraction and allow for ztsd to have its shrinker for its extra > workspaces. You can even use the list_lru stuff to make it super simple, then > you don't have to worry about all the infrastructure. Thanks, > Nevermind, I missed that you also change the get side to lookup the workspace for the compression level instead of cycling through the idle_ws list. In that case this is fine by me. Reviewed-by: Josef Bacik Thanks, Josef