probably you should try to use many more clients?
did you really think - it function have a dependence to number a clients?
+static inline struct osd_oi * +osd_fid2oi(struct osd_device *osd, const struct lu_fid *fid) +{ + if (!fid_is_norm(fid)) + return NULL; + + LASSERT(osd->od_oi_table != NULL && osd->od_oi_count >= 1); + /* It can work even od_oi_count equals to 1 although it's unexpected, + * the only reason we set it to 1 is for performance measurement */ + return &osd->od_oi_table[fid->f_seq & (osd->od_oi_count - 1)]; +}
f_seq & osd->od_oi_count - will don't depend to number a clients as uses only lower bits.
why don't use fid_hash() instead ?
f_seq depends on the number of the clients indirectly.
and we use only lower bits of it ? 
seq may be in range 0 .. 64 not more
you don't answer - why don't use fid_hash with better distribution ? if we have one line change and replace fid->f_seq with fid_hash(fid) distribution will changed dramatically and all files will be used.
seq isn't limited at all. seq is per client, then every client uses upto 128K oids and gets a new sequences. imagine 10K clients mount and start to generate roughly similar workload, they all will be sending roughly same f_oid..
Alex,
please look carefully to function - seq & (fid_files_num -1) so only lower bits used - so seq limited to 1-64.
probably Liang can comment better. I'd suggest to use more clients to see how the function behaves really. a single client is a very special case. and even in this case few OI files were used which is good.
yes, my intention is hashing different clients to different OI files, so we don't have all clients contend on all OIs all the time (drawback of fid_hash). Also, because we have 64 OI files, so seq & (osd->od_oi_count - 1) should be between 0-63, is there any issue at here?
Liang,
distribution too bad in case few clients, as lower bits is mostly same for these clients (seq always allocated 128 fid's range), so only few files used after test. from disk perspective any parallel access add additional seeks so not have a differences is different clients work on same file or not.
I don't think performance bottleneck is going to be OI operations when there are very few clients, also, why do we bother to use all OI files parallelly for handful clients? There was a single OI for whole filesystem in 2.0/2.1, multiple OIs were added to improve aggregated performance for many clients, not for single client.