Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754571AbbHINmz (ORCPT ); Sun, 9 Aug 2015 09:42:55 -0400 Received: from mail.parknet.co.jp ([210.171.160.6]:52356 "EHLO mail.parknet.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753972AbbHINmt (ORCPT ); Sun, 9 Aug 2015 09:42:49 -0400 From: OGAWA Hirofumi To: Jan Kara Cc: Daniel Phillips , David Lang , Rik van Riel , tux3@tux3.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org Subject: Re: [FYI] tux3: Core changes References: <20150526070910.GA3307@quack.suse.cz> <20150526090058.GA8024@quack.suse.cz> <5564D60E.6000306@phunq.net> <20150527084138.GD2590@quack.suse.cz> <87a8vtdqfz.fsf@mail.parknet.co.jp> <20150623161247.GP2427@quack.suse.cz> <87k2ueepd6.fsf@mail.parknet.co.jp> <20150709160528.GK2900@quack.suse.cz> <874mklaqbn.fsf@mail.parknet.co.jp> <20150803134251.GC9657@quack.suse.cz> Date: Sun, 09 Aug 2015 22:42:42 +0900 In-Reply-To: <20150803134251.GC9657@quack.suse.cz> (Jan Kara's message of "Mon, 3 Aug 2015 15:42:51 +0200") Message-ID: <87r3nck27h.fsf@mail.parknet.co.jp> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2372 Lines: 55 Jan Kara writes: > I'm not sure about which ENOSPC issue you are speaking BTW. Can you > please ellaborate? 1. GUP simulate page fault, and prepare to modify 2. writeback clear dirty, and make PTE read-only 3. snapshot/reflink make block cow 4. driver called GUP modifies page, and dirty page without simulate page fault >> If you claim, there is strange logic widely used already, and of course, >> we can't simply break it because of compatibility. I would be able to >> agree. But your claim sounds like that logic is sane and well designed >> behavior. So I disagree. > > To me the rule: "Do not detach a page from a radix tree if it has an elevated > refcount unless explicitely requested by a syscall" looks like a sane one. > Yes. > >> > And frankly I fail to see why you and Daniel care so much about this >> > corner case because from performance POV it's IMHO a non-issue and you >> > bother with page forking because of performance, don't you? >> >> Trying to penalize the corner case path, instead of normal path, should >> try at first. Penalizing normal path to allow corner case path is insane >> basically. >> >> Make normal path faster and more reliable is what we are trying. > > Elevated refcount of a page is in my opinion a corner case path. That's why > I think that penalizing that case by waiting for IO instead of forking is > acceptable cost for the improved compatibility & maintainability of the > code. What is "elevated refcount"? What is difference with normal refcount? Are you saying "refcount >= specified threshold + waitq/wakeup" or such? If so, it is not the path. It is the state. IOW, some group may not hit much, but some group may hit much, on normal path. So it sounds like yet another "stable page". I.e. unpredictable performance. (BTW, by recall of "stable page", noticed "stable page" would not provide stabled page data for that logic too.) Well, assuming "elevated refcount == threshold + waitq/wakeup", so IMO, it is not attractive. Rather the last option if there is no others as design choice. Thanks. -- OGAWA Hirofumi -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/