Hello, Lai. On Wed, Feb 06, 2013 at 12:19:26AM +0800, Lai Jiangshan wrote: > > Can't we just make get_work_pool_id() do a fast path if OFFQ than > > requiring the user to distinguish off and on queue cases? > > old code, get_work_pool_id() is only called when offq. > after series applied, offq_work_worker_id() *must* be called only when offq, > and we can't offer get_work_worker_id().
Can you please elaborate why we can't offer get_work_worker_id()? > > While I'm a bit worried about capping total number of workers by the > > amount bits left in work->data, if that doesn't cause any practical > > issue (how many do we have available on 32bit?), I think this is the > > better approach. We couldn't do this before because work -> worker > > relationship could be 1:N but it should now be doable. Note that we > > need RCU no matter what we index (pool or worker) to avoid locking on > > each lookup. > > BUILD_BUG_ON((BITS_PER_LONG != 64) && (WORK_OFFQ_WORKER_SHIFT > 12)); > > Every worker needs at least 4k memory for its stack, the bits are enough if > WORK_OFFQ_WORKER_SHIFT <= 12. Ah, so that was what that comment was about, so we always have enough bits. I have to say the comment is a bit cryptic. > > From past experience, I *think* it's gonna be a bit of struggle for > > both of us to get the series in a shape that I would find acceptable > > by reviewing and iterating, so I might just swallow it and regurgitate > > into a form that I like. Hmm.... dunno. Will think about it. > > It is not nightmare for me! the work and discusses will consume most > time of my night, no night time for nightmare. Heh, yeah, I didn't say it was a nightmare. I do like your work. I think most problems are from communication (including description and comments). I guess I can help along for a while. > > Anyways, nice work. > > > I'm glad you like it. My daughter was born about 3month ago and I left > workqueue work then. I think it is time to pick up old pending > patches. Big congratulations. :) Thanks! -- tejun -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
