[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9685.1164107326@redhat.com>
Date: Tue, 21 Nov 2006 11:08:46 +0000
From: David Howells <dhowells@...hat.com>
To: Christoph Hellwig <hch@...radead.org>
Cc: Trond Myklebust <trond.myklebust@....uio.no>,
David Howells <dhowells@...hat.com>, torvalds@...l.org,
akpm@...l.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] WorkStruct: Shrink work_struct by two thirds
Christoph Hellwig <hch@...radead.org> wrote:
> > Why not simply add a timer argument to 'queue_delayed_work()' and
> > 'cancel_delayed_work()'? That may allow you to reuse an existing timer
> > struct if you already have it embedded somewhere else.
>
> I doubt we can really reuse an existing timer,
I have to agree with Christoph on that. I don't think reusing an existing
timer is going to work in most of the cases - in many cases there isn't an
existing timer to reuse, and even if there is, it's usually there for some
other purpose.
> but this seems to be the cleanest way despite that. Let's follow the
> philosophy of builing from small building blocks for our kernel APIs aswell.
I'm not so sure of that. Currently the rest of the kernel is unaware there's a
timer there and doesn't have to do anything about it directly.
> As a second benefit it also makes handling the case of having both delayed
> and immediate items on a single workqueue trivial.
It's pretty straightforward as it is now. The worst bit is that we have to
have several functions that do the same or a similar thing but with different
names because they take different arguments.
The benefit of what we have at the moment is that there is only one timer
callback routine required and everything uses that - not that we can't just
export that, but it's cleaner to set things up since the rest of the kernel
doesn't know there's a timer involved.
David
-
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