On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Ok, updated version.
>
> One thing I found a bit awkward was the way its putting all inodes
> in the root of the relayfs namespace, with the cpuid tacked on the
> end of the bde
On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Ok, updated version.
>
> One thing I found a bit awkward was the way its putting all inodes
> in the root of the relayfs namespace, with the cpuid tacked on the
> end of the bde
On Wed, Aug 31 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> > relayfs read update from the previous mail [*] as well.
>
> There's a small memory leak there on one
Nathan Scott writes:
> Hi Tom,
>
> On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
> > You're right, it should be using simple_rmdir rather than
> > simple_unlink for removing directories. Thanks for sending the patch,
>
> No problem.
>
> > which I've modified a bit to avo
On Wed, Aug 31, 2005 at 02:33:10PM +1000, Nathan Scott wrote:
> ...
> On an unrelated note, are there any known issues with using epoll
> on relayfs file descriptors? I'm having a few troubles, and just
> wondering if its me doing something silly, or if its known to not
> work...? Symptoms of the
Hi Tom,
On Tue, Aug 30, 2005 at 11:19:04PM -0500, Tom Zanussi wrote:
> You're right, it should be using simple_rmdir rather than
> simple_unlink for removing directories. Thanks for sending the patch,
No problem.
> which I've modified a bit to avoid splitting the rmdir/unlink cases
> into separ
Nathan Scott writes:
> Hi there,
>
> On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
> > ...
> > # find /relay
> > /relay
> > /relay/block
> > /relay/block/sdd
> > /relay/block/sdd/trace3
> > /relay/block/sdd/trace2
> > /relay/block/sdd/trace1
> > /relay/block/sdd/trace0
Hi there,
On Wed, Aug 31, 2005 at 09:48:23AM +1000, Nathan Scott wrote:
> ...
> # find /relay
> /relay
> /relay/block
> /relay/block/sdd
> /relay/block/sdd/trace3
> /relay/block/sdd/trace2
> /relay/block/sdd/trace1
> /relay/block/sdd/trace0
> /relay/block/sdb
> /relay/block/sdb/trace3
> /relay/blo
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> Ok, updated version.
One thing I found a bit awkward was the way its putting all inodes
in the root of the relayfs namespace, with the cpuid tacked on the
end of the bdevname - I was a bit confused at first when a trace of
sdd
Hi Jens,
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> relayfs read update from the previous mail [*] as well.
There's a small memory leak there on one of the start-tracing
error paths (relay_open failure).
On Mon, Aug 29 2005, Nathan Scott wrote:
> On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> > ...
> > Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> > relayfs read update from the previous mail [*] as well.
>
> Hi Jens,
>
> There's a minor config botch in
On Wed, Aug 24, 2005 at 11:28:39AM +0200, Jens Axboe wrote:
> ...
> Patch attached is against 2.6.13-rc6-mm2. Still a good idea to apply the
> relayfs read update from the previous mail [*] as well.
Hi Jens,
There's a minor config botch in there, I get this:
scripts/kconfig/conf -s arch/i386/Kco
On Wed, Aug 24 2005, Jens Axboe wrote:
> On Wed, Aug 24 2005, Nathan Scott wrote:
> > On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> > > ...
> > > This isn't msec precision, it's usec. sched_clock() is in ns! I already
> > > decided that msec is too coarse, but usec _should_ be enoug
On Wed, Aug 24 2005, Nathan Scott wrote:
> On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> > ...
> > This isn't msec precision, it's usec. sched_clock() is in ns! I already
> > decided that msec is too coarse, but usec _should_ be enough.
>
> Right you are (I was thinking m-for-micro
On Wed, Aug 24, 2005 at 09:08:10AM +0200, Jens Axboe wrote:
> ...
> This isn't msec precision, it's usec. sched_clock() is in ns! I already
> decided that msec is too coarse, but usec _should_ be enough.
Right you are (I was thinking m-for-micro, not m-for-milli in my head ;)
- but still, there do
On Wed, Aug 24 2005, Nathan Scott wrote:
> On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> > Hi,
> >
> > This is a little something I have played with. It allows you to see
> > exactly what is going on in the block layer for a given queue. Currently
> > it can logs request queueing a
On Wed, Aug 24 2005, Nathan Scott wrote:
> Hi Jens,
>
> On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> > ...
> > + t.pid = current->pid;
> > ...
> > +/*
> > + * The trace itself
> > + */
> > +struct blk_io_trace {
> > + u32 magic; /* MAGIC << 8 | version *
Hi Jens,
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> ...
> + t.pid = current->pid;
> ...
> +/*
> + * The trace itself
> + */
> +struct blk_io_trace {
> + u32 magic; /* MAGIC << 8 | version */
> + u32 sequence; /* event number */
> +
On Tue, Aug 23, 2005 at 02:32:36PM +0200, Jens Axboe wrote:
> Hi,
>
> This is a little something I have played with. It allows you to see
> exactly what is going on in the block layer for a given queue. Currently
> it can logs request queueing and building, dispatches, requeues, and
> completions.
Hi,
This is a little something I have played with. It allows you to see
exactly what is going on in the block layer for a given queue. Currently
it can logs request queueing and building, dispatches, requeues, and
completions. I've uploaded a little silly app to do dumps here:
http://www.kernel.o
20 matches
Mail list logo
