On Saturday 16 August 2014 at 15:35:42, Edward Shishkin wrote: > > On 08/16/2014 01:27 PM, Ivan Shapovalov wrote: > > On Saturday 16 August 2014 at 10:23:08, Edward Shishkin wrote: > >> [...] > >>>> So I need to find a way to take rwsem in a read-biased mode... Any > >>>> advice is > >>>> accepted, including "give up with adding of yet another lock and go with > >>>> multiple transactions" :) > >>> > >>> IMHO this is too complicated. > >>> > >>> Why don't you want to grab, say, 20M per iteration? > >>> It should work without any problems, just maintain a > >>> counter of blocks allocated in the iteration.. > > I see it mostly like a "good to have" thing. > > > Nop, we discuss the reasonable implementation of the "must have" - > space reservation by the fitrim process.. > > > > When the system is under load, > > FITRIM implemented in this "simple" way will be ineffective: it will miss > > some blocks that are temporarily allocated (journal, etc.) > > > It will be perfectly discarded by the realtime discard > > > > even though it is > > theoretically possible to stop accepting new transactions, commit all existing > > ones and perform discard while the system is artificially made idle, then > > resume everything. > > > IMHO complicated and not need. > Anyway, missing 2 blocks per device is not critical. OK. Giving up then. Let's go the multiple transaction approach. > > > > > > So I've been trying to check if this is feasible. Looks like it isn't. > > > >> add the counter to the struct reiser4_context and > >> set it to zero at the beginning of every iteration. > >> use get_current_context() to access the counter. > > Is it needed? The simple way is just a loop consisting of > > - grab space > > - allocate blocks forward from start position (initially 0) until end of > > partition or limit reached > > - update start position to `last allocated block + 1` > > - put allocated space to the delete set > > - mark for force-committing > > - reiser4_txn_restart_current() > > - if we've reached end of partition earlier, break, otherwise loop > > > > > Ok, it will also work (with more iterations, though), > well, let's do so.. More iterations? It seems like I don't really understand your idea with the counter. Could you please elaborate a bit? Thanks, -- Ivan Shapovalov / intelfx /
Attachment:
signature.asc
Description: This is a digitally signed message part.
