On Wed, May 13, 2020 at 08:13:58AM +0200, Wolfgang Denk wrote: > Dear Piergiorgio, > > In message <20200512161731.GE7261@xxxxxxxx> you wrote: > > > > > This still does not really explain what is so slow here. I mean, > > > even if the locking was an expenive operation code-wise, I would > > > expect to see at least one of the CPU cores near 100% then - but > > > botch CPU _and_ I/O are basically idle, and disks are _all_ and > > > _always_ really close at a trhoughput of 400 kB/s - this looks like > > > some intentional bandwith limit - I just can't see where this can be > > > configured? > > > > The code has 2 functions: lock_stripe() and > > unlock_all_stripes(). > > > > These are doing more than just lock / unlock. > > First, the memory pages of the process will > > be locked, then some signal will be set to > > "ignore", then the strip will be locked. > > > > The unlock does the opposite in the reverse > > order (unlock, set the signal back, unlock > > the memory pages). > > The difference is that, whatever the reason, > > the unlock unlocks *all* the stripes, not > > only the one locked. > > > > Not sure why. > > It does not matter how omplex the operation is - I wonder why it is > taking so long: it cannot be CPU bound, as then I would expect to > see any significant CPU load, but none of the cores shows more than > 5...6% usage, ever. Or it is I/O bound, then I would expect to see > I/O wait, but this is also never more than 0.2...0.3%. > > And why are all disks running at pretty exaclty 400 kB/s read rate, > all the time? this looks like some intentinal bandwith limit, but I > cannot find any knob to change it. In my test I see 1200KB/sec, or 1.2MB/sec, which is different than yours. I do not think there is any bandwidth limitation, otherwise we should see the same, I guess. The low CPU load and low data rate seems to me a symptom of CPU just systematically waiting (for something). It would be like putting in the code, here and there, some usleep(). In the end we'll see low CPU load and low data rate, *but* very constant. Likely, is not either I/O wait, but some other wait. It could be not the lock stripe, but the locking of the process memory pages... This could be easily test, BTW. Maybe I'll try... bye, pg > > > > Best regards, > > Wolfgang Denk > > -- > DENX Software Engineering GmbH, Managing Director: Wolfgang Denk > HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany > Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@xxxxxxx > Be careful what you wish for. You never know who will be listening. > - Terry Pratchett, _Soul Music_ -- piergiorgio
