Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753715Ab1CJS6V (ORCPT ); Thu, 10 Mar 2011 13:58:21 -0500 Received: from smtp-out.google.com ([74.125.121.67]:61511 "EHLO smtp-out.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753320Ab1CJS6S convert rfc822-to-8bit (ORCPT ); Thu, 10 Mar 2011 13:58:18 -0500 DomainKey-Signature: a=rsa-sha1; c=nofws; d=google.com; s=beta; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; b=qRlXRJijiDg2eFcycdlDiB3015dKkBN/UcOhW2rbLMcOlUIZN9oq5ZgAJoA63pnf1Z pQxJ7WLIz7sh9YJrOuiw== MIME-Version: 1.0 In-Reply-To: <20110310181529.GF29464@redhat.com> References: <1299619256-12661-1-git-send-email-teravest@google.com> <20110309142237.6ab82523.kamezawa.hiroyu@jp.fujitsu.com> <20110310181529.GF29464@redhat.com> From: Justin TerAvest Date: Thu, 10 Mar 2011 10:57:52 -0800 Message-ID: Subject: Re: [RFC] [PATCH 0/6] Provide cgroup isolation for buffered writes. To: Vivek Goyal Cc: KAMEZAWA Hiroyuki , m-ikeda@ds.jp.nec.com, jaxboe@fusionio.com, linux-kernel@vger.kernel.org, ryov@valinux.co.jp, taka@valinux.co.jp, righi.andrea@gmail.com, guijianfeng@cn.fujitsu.com, balbir@linux.vnet.ibm.com, ctalbott@google.com, nauman@google.com, mrubin@google.com Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-System-Of-Record: true Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2045 Lines: 48 On Thu, Mar 10, 2011 at 10:15 AM, Vivek Goyal wrote: > On Thu, Mar 10, 2011 at 10:08:03AM -0800, Justin TerAvest wrote: > > [..] >> > I don't like to increase size of page_cgroup but I think you can record >> > information without increasing size of page_cgroup. >> > >> > A) As Andrea did, encode it to pc->flags. >> > ? But I'm afraid that there is a racy case because memory cgroup uses some >> > ? test_and_set() bits. >> > B) I wonder why the information cannot be recorded in page->private. >> > ? When page has buffers, you can record the information to buffer struct. >> > ? About swapio (if you take care of), you can record information to bio. >> >> Hi Kame, >> >> I'm concerned that by using something like buffer_heads stored in >> page->private, we will only be supported on some filesystems and not >> others. In addition, I'm not sure if all filesystems attach buffer >> heads at the same time; if page->private is modified in the flusher >> thread, we might not be able to determine the thread that dirtied the >> page in the first place. > > I think the person who dirtied the page can store the information in > page->private (assuming buffer heads were not generated) and if flusher > thread later ends up generating buffer heads and ends up modifying > page->private, this can be copied in buffer heads? This scares me a bit. As I understand it, fs/ code expects total ownership of page->private. This adds a responsibility for every user to copy the data through and store it in the buffer head (or anything else). btrfs seems to do something entirely different in some cases and store a different kind of value. I don't know that it's right to add the burden to copy the original value to everything that wants to use page->private. > > Thanks > Vivek > -- 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/