On Tue, May 11 2010 at 12:23am -0400, Kiyoshi Ueda <k-ueda@xxxxxxxxxxxxx> wrote: > Hi Mike, > > On 05/11/2010 07:55 AM +0900, Mike Snitzer wrote: > > Revert back to only allocating a minimalist request_queue structure > > initially (needed for both bio and request-based DM). Initialization of > > a full request_queue (request_fn, elevator, etc) is deferred until it is > > known that the DM device is request-based. > > Thank you for working on this. > However, I still disagree with this patch as we discussed on this thread: > http://marc.info/?t=124990138700003&r=1&w=2 > (Exporting a part of queue's features may cause some maintenance costs > in future.) Thanks for the reference. I completely forgot about that thread (even though I responded to Nikanth's patches in detail! :) It is clear we need to resolve the current full request_queue initialization that occurs even for bio-based DM devices. I believe the 2 patches I posted accomplish this in a stright-forward way. We can always improve on it (by looking at what you proposed below) but we need a minimlaist fix that doesn't depend on userspace LVM2 changes right now. Interestingly, having to revisit this issue (forgetting that this line of work was already explored) I came up with roughly the same type of change to the block layer as Nikanth's 1/2 patch. The difference being my blk_init_allocated_queue is more minimalist because the block code has evolved to allow this change to be more natural. Similarly, my proposed DM changes are also quite natural. By using dm_table_set_type() as the hook to initialize the request-based DM device's elevator we perform allocations during table load. Having just looked at Nikanth's proposed DM patch 2/2 again it shows that blk_init_allocated_queue(), which allocates memory, was being called during resume (dm_swap_table). Allocations are not allowed during resume. > As I mentioned on the last email of the thread above (see below), > specifying device type at the device creation time by userspace tools > should make dm code very simple. So that may be a better approach. > > > By the way, another approach to optimizing the memory usage would be > > to determine whether the dm device is bio-based or request-based > > at the device creation time, instead of the table binding time. > > We want the delayed allocation, since kernel can't decide the device > > type until the first table is bound because of the auto-detection > > mechanism. The auto-detection is good for keeping compatibility with > > existing user-space tools. But once user-space tools are changed to > > specify device type at the device creation time, we can eventually > > remove the auto-detection. > > Then, kernel can decide device type in alloc_dev(), so > > the initialization code in kernel will become very simple. > > Thanks, > Kiyoshi Ueda -- dm-devel mailing list dm-devel@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/dm-devel
