>>> The Lee-Man <[email protected]> schrieb am 19.11.2014 um 19:35 in Nachricht <[email protected]>: > On Tuesday, November 18, 2014 10:55:31 PM UTC-8, Uli wrote: >> >> >>> Lee Duncan <[email protected] <javascript:>> schrieb am 18.11.2014 >> um 22:35 in >> Nachricht <1416346536-18198-1-git-seemail-###-duncan@ <javascript:>###>: >> > The following patch fixes a problem where the CPU becomes compute bound >> > when rediscovering targets, when there are hundreds of sessions. >> > >> > When his occurs, most of the time is spent in the function >> > iscsi_sysfs_for_each_session(). This function does a scandir(), >> > sorted alphabetically, to get a list of sessions, then scans >> > that list looking for a match. When there are hundreds of sesions >> > this can take forever. >> >> >> I wonder: What takes forever: reading hundreds of sysfs entries, sorting >> them, or looking for a match? I guess none of them should take forever >> unless the algorithm is really very bad. >> > > The problem is not the sort, since the patch still does a sort of the > directory entries. > > I believe the problem is in processing the sorted data, in > iscsi_sysfs_for_each_session(). This function does dozens or more > open/read/close cycles on sysfs attributes. Multiply that times hundreds of > session, and you have tens of thousands I/O operations. This fix ensures > that, much of time, this loop is only gone through once.
When the reason for the sort is just to find some extrema (min or max), the sort is not needed. Also when just needing some extreme entry (min or max) it makes little sense to populate some array with all entries just to discard them all, but one. I don't know the details, but if all the other stuff isn't needed, it shouldn't be read. What I saw from your path is that you just cheat on the sort routine. So if getting the entries takes all the time (I guess it happens before sorting), I don't see how you save a lot of time that way, _unless_ the compare routine actually does I/O to compare the values which is bad, because every value is compared more than once in a typical sort. > > >> > >> > This patch saves the current session and then ensures that this >> > session sorted to the front of the list. Testing shows that >> > CPU usage goes from near 100% to near 0% when running cable >> > plug tests with hundreds of sessions. >> > >> > Signed-off-by: Lee Duncan <[email protected] <javascript:>> >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups >> > "open-iscsi" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> an >> > email to [email protected] <javascript:>. >> > To post to this group, send email to [email protected] >> <javascript:>. >> > Visit this group at http://groups.google.com/group/open-iscsi. >> > For more options, visit https://groups.google.com/d/optout. >> >> >> >> >> > > -- > You received this message because you are subscribed to the Google Groups > "open-iscsi" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/open-iscsi. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "open-iscsi" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/open-iscsi. For more options, visit https://groups.google.com/d/optout.
