[linux-cifs-client] Re: What is GetXid/FreeXid supposed to actually do?

[Jeff Layton]

On Sun, 24 May 2009 15:38:22 -0500
Steve French <smfrench at gmail.com> wrote:

> On Sun, May 24, 2009 at 2:31 PM, Christoph Hellwig <hch at infradead.org> wrote:
> > On Sun, May 24, 2009 at 03:21:07PM -0400, Jeff Layton wrote:
> >> Any objection to just replacing this xid value with the pid or tgid
> >> instead? Does this xid value give you anything that that doesn't?
> >
> > Yeah, from all that I can see there is always at most one xid in
> > use per thread.  So just replacing it with a tgid should work easily.
> > Even better would be replacing all that ad-hoc debugging with the
> > ftrace event tracer.
> 
> That may work (using the tgid) but there are various cases where it was
> helpful to distinguish log entries this way (rather than simply using
> timestamps,
> especially since dmesg is lossy so you don't always see the function entry
> and exits) when you have multiple requests in a series from one or more threads
> request from thread1, request from thread 2, request 2 from thread1,
> request 2 from thread 2 etc.
> 

dmesg is never lossy...maybe you mean syslog?

Anyway, there are never multiple requests in flight from single threads
in cifs. In all cases, a thread transmits a request and then goes to
sleep until the reply comes in.

AFAICT too, this xid only ever shows up in one cERROR message:

    cERROR(1, ("Frame too large received.  Length: %d  Xid: %d",
		receive_len, xid));

...that just doesn't seem like it's worth the cost.

> Using the ftrace event tracer may be good enough for some of this
> (except the stats gathering, counters) - any pointers to its
> use in NFS?
> 

I know Steve D. has been working on tracepoints for nfs, but I haven't
given them a hard look as of yet.

While we're talking about reengineering this stuff, it sure would be
nice to move all of the ad-hoc files under /proc/fs/cifs to standard
module parameters as well...

-- 
Jeff Layton <jlayton at redhat.com>