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
