Okay, I spent most the day yesterday playing with the
code in question, i.e. the open-iscsi code that rescans
the session list looking for the current session.

In particular, I was looking at update_sessions().

One thing I noticed is that this code only gets executed
if discovery.sendtargets.use_discoveryd is set to Yes for
a particular target, by the way.

Bottom line: I did not find any way to significantly speed
up the search other than the "cache the last session"
patch I already posted.

Here's the problem: the submitted patch makes this
particular use case O(1). You can't get much faster
than that, i.e. it takes a fixed time no matter how
many sessions are present.

The only patches I can come up with make that
search take O(n). That's because the only
way other than caching to find the "last session
used" is to search through the session list.

Are there optimization that could be done in this code?
Yes, of course. It hasn't been touched in a while, is
not usually in the critical path, and generally works,
so nobody messes with it much.

But I believe those optimizations are unwarranted
given the fact that they are in the noise compared
to sysfs read delays I have seen.

So my previous patch submission stands.

Mike: what are your thoughts? Users that
have many many sessions need this. I'm open
to alternative solutions, I just don't see any.

Bottom line: there is no simple way to find a
particular open-iscsi session from /sysfs without
reading and comparing several strings, so any
fix that reduces the time per entry will still leave
the search at O(n). The solution has to be a
way to make this time fixed, not linear, as
the submitted patch does.

-- 
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 open-iscsi+unsubscr...@googlegroups.com.
To post to this group, send email to open-iscsi@googlegroups.com.
Visit this group at http://groups.google.com/group/open-iscsi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to