From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754096AbYAXART (ORCPT ); Wed, 23 Jan 2008 19:17:19 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1752505AbYAXARL (ORCPT ); Wed, 23 Jan 2008 19:17:11 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]:57503 "EHLO extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751691AbYAXARK (ORCPT ); Wed, 23 Jan 2008 19:17:10 -0500 Date: Thu, 24 Jan 2008 00:03:36 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@blonde.site To: Linus Torvalds cc: Miklos Szeredi , a.p.zijlstra@chello.nl, salikhmetov@gmail.com, linux-mm@kvack.org, jakob@unthought.net, linux-kernel@vger.kernel.org, valdis.kletnieks@vt.edu, riel@redhat.com, ksm@42.dk, staubach@redhat.com, jesper.juhl@gmail.com, akpm@linux-foundation.org, protasnb@gmail.com, r.e.wolff@bitwizard.nl, hidave.darkstar@gmail.com, hch@infradead.org Subject: Re: [PATCH -v8 3/4] Enable the MS_ASYNC functionality in sys_msync() In-Reply-To: Message-ID: References: <12010440803930-git-send-email-salikhmetov@gmail.com> <1201044083504-git-send-email-salikhmetov@gmail.com> <1201110066.6341.65.camel@lappy> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 23 Jan 2008, Linus Torvalds wrote: > > So we certainly *could* make ramfs/tmpfs claim they do dirty accounting, > but just having a no-op writeback. Without that, they'd need something > really special in the file time updates. What we might reasonably choose to end up doing there (in 2.6.25) is sending tmpfs etc. through the extra faulting for linked files, but skipping it as at present for unlinked files i.e. shared memory would continue to skip the extra faults, shared memory being the case we really wanted to avoid the overhead on when dirty page accounting came in. > Personally, I don't really see anybody really caring one way or the other, > but who knows.. I care a bit, because I don't like to feel that tmpfs is now left saddled with the bug that every filesystem has had for years before. I'll need to compare the small performance cost of fixing it against the unease of leaving it alone. Hugh