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

[Jeff Layton]

On Sun, 24 May 2009 13:16:21 -0500
Steve French <smfrench at gmail.com> wrote:

> On Sun, May 24, 2009 at 8:14 AM, Jeff Layton <jlayton at redhat.com> wrote:
> > As Christoph pointed out while looking at this code, we have a bunch of
> > calls in cifs to GetXid/FreeXid, but the xid's returned aren't actually
> > used for anything aside from the occasional debug message.
> 
> The original intent of the GetXid and FreeXid macros was to log
> function entry and exit in a consistent way (since there was no VFS
> wide tracing facilty to log these), and to bump perf counters which
> indicate how many requests are currently in cifs, and how many total
> vfs requests, and to return a number that could be used for
> filtering/sorting log messages associated with each unique VFS request
> into cifs (not just each kernel tread).   If there is a better way to
> accomplish those goals now, it could be removed.    I frequently use
> them in debugging (by selectively turning on one of the 3 logging
> flags in /proc/fs/cifs/cifsFYI).   I also frequently use the counters
> which indicate how many requests are in the cifs VFS at that time.
> 
> > Not only that, but these values aren't even unique. It's easily
> The values don't have to be unique since they are used for debugging
> only, but obviously when they are going to be used to filter debug
> messages out of the log they would have more value if unique.

The problem is that we're adding serialization behind a global spinlock
with these calls. Granted, the ops done while holding that spinlock are
quick, but this probably has at least some performance cost.

There's also the matter that we end up getting these values at a fairly
high level, and then have to pass them down to much lower levels.
Adding extra args to a function adds to the complexity.

I'm not opposed to having code in that makes debugging easier, but this
seems a bit more costly than debugging infrastructure should be.

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?

-- 
Jeff Layton <jlayton at redhat.com>