Re: [PATCH v2] staging: greybus: use inline function for macros

[Greg KH <gregkh@linuxfoundation.org>]

On Thu, Mar 23, 2023 at 10:35:59AM +0530, Deepak R Varma wrote:
> On Thu, Mar 23, 2023 at 05:58:02AM +0100, Greg KH wrote:
> > Nice, that shows that it is the same both ways as the compiler version
> > you are using is smart enough
> > 
> > Which compiler and version is this?  Does it work the same for all of
> > the supported versions we have to support (i.e. really old gcc?)
> > 
> > For the most part, sysfs files are not on any sort of "fast path" so a
> 
> Hello,
> Is there a guideline/documentation on how to identify if a code is part of
> fast/slow path?

Not really, the general rule is if the code is used in a function that
is time criticial, then it is in the "fast path".

Normally the code path for I/O or for determining what process to
schedule next is a "fast path" as you want to do the least amount of
work in the kernel so as to get the I/O to the hardware or caller, or
you want to schedule the next process faster so that it can do the real
work that is wanted.

But for some I/O, where the hardware is the limiting factor (like slow
USB or serial connections), no matter how optimized the kernel is, the
data can not get to the user any faster because the hardware just can
not provide it, so for that, it's not really that critical.

Note that "time critical" can change depending on the user of the system
and as hardware evolves.

One example would be the creation of a number of sysfs entries for the
disks in the systems.  On a "normal" system, creating them all is trivial
as there are not many disks.  But on some "big" systems with many tens
of thousands of disks, it can become a boot time bottleneck.

So it's usually "you know it when you see it show up on a profile", use
the perf tool to test your workload on, to see where in the kernel
things are taking up too much time so you know what needs to be made
faster.

hope this helps,

greg k-h