[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEsagEiT_=G5tnvLFyuYJ=UU-ixOzJEg5-12p7b0A=qqkshGAg@mail.gmail.com>
Date: Thu, 27 Jun 2013 20:00:32 -0700
From: Daniel Phillips <daniel.raymond.phillips@...il.com>
To: "Theodore Ts'o" <tytso@....edu>,
OGAWA Hirofumi <hirofumi@...l.parknet.co.jp>,
Dave Chinner <david@...morbit.com>,
Al Viro <viro@...iv.linux.org.uk>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-fsdevel@...r.kernel.org" <linux-fsdevel@...r.kernel.org>,
"tux3@...3.org" <tux3@...3.org>
Subject: Re: [PATCH] Optimize wait_sb_inodes()
Hi Ted,
On Thu, Jun 27, 2013 at 11:36 AM, Theodore Ts'o <tytso@....edu> wrote:
> If the goal is to optimize file system freeze operations, sure. But
> that's also not a common operation, so if it burns a little extra CPU
> time, it wouldn't cause me to think that it was a high priority issue.
> Decreasing the wall clock time for a file system freeze operation
> would probably be a far more interesting goal.
Personally, any extra CPU burn bothers me. Maybe I am just
obsessive about that. Anyway, extra CPU usually does translate
into wall clock time, so optimizing sync would seem to be worth
the price of admission by that criterion alone. In general it's hard
to see why syncing fast and efficiently could ever be a bad thing.
I agree, not high priority. Not useless either. I see it more as a fit
and finish thing.
Regards,
Daniel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists