Skip to contentSkip to conversation

as_arq scheduler alloc with 2.6.0-test8-mm1

DISCUSSION Amit Patel 2 participants 2 messages Oct 29, 2003 1 message not in the archive

lore
Share & tools
lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Amit Patel

author
#1 lore raw
Quoted 11 lines · --- Nick Piggin

No, you're on the right track. Actually, in the block device
you will allocate the queue, and the queue will then allocate
the elevator. First see if the queue is being properly allocated
and freed. If it is not, then the problem is in the SCSI layer.

Hi Nick,

During scsi_scan.c:scsi_probe_and_add_lun it allocates scsi device and request_queue to send the scsi_request. If during this scan it finds no device attached to target it will deallocate request__queue. But since there was no disk found it never called add_disk and so it never go through blk_register_queue function to register elevator queue. So during clean up it just calles blk_cleanup_queue which does _not_ clean up elevator_data.

This is just what I think is happening by looking at the code. I might be missing something. But in this case either blk_cleanup_queue should clean elevator also as part of cleanup instead of it getting cleaned up through blk_unregister_queue or scsi layer needs to make some changes during scan. I do not know what implication it might have if cleanup is done as part of blk_cleanup_queue on other kind of block devices. I will try to put this cleanup as part of blk_cleanup_queue to see if it works.

Thanks
Amit

Quoted 14 lines
Quoted 3 lines · Amit Patel

Hi

After doing some printk debugging looks like for

each

Quoted 3 lines

block device we allocate elevator structure. But during cleanup the elevator->elevator_data is never freed. In printk I put printk in

as-iosched.c:as_alloc

Quoted 2 lines

where I see elevator_data is allocated from as_arq pool and it should have been freed as a part of

block

Quoted 14 lines
Quoted 4 lines

device cleanup through elevator_release function. I never see it coming to elevatore_release function.

I will try to walk through code some more and see

if I

Quoted 2 lines

can figure out who was supposed to call elevator_release as part of cleanup. Let me know if

I

Quoted 5 lines

am going on wrong track here.

Thanks
Amit

__________________________________
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears
http://launch.yahoo.com/promos/britneyspears/

#2 lore raw
Quoted 26 lines · Amit Patel
Quoted 11 lines · --- Nick Piggin

No, you're on the right track. Actually, in the block device
you will allocate the queue, and the queue will then allocate
the elevator. First see if the queue is being properly allocated
and freed. If it is not, then the problem is in the SCSI layer.

Hi Nick,

During scsi_scan.c:scsi_probe_and_add_lun it allocates scsi device and request_queue to send the scsi_request. If during this scan it finds no device attached to target it will deallocate request__queue. But since there was no disk found it never called add_disk and so it never go through blk_register_queue function to register elevator queue. So during clean up it just calles blk_cleanup_queue which does _not_ clean up elevator_data.

Quoted 11 lines

This is just what I think is happening by looking at the code. I might be missing something. But in this case either blk_cleanup_queue should clean elevator also as part of cleanup instead of it getting cleaned up through blk_unregister_queue or scsi layer needs to make some changes during scan. I do not know what implication it might have if cleanup is done as part of blk_cleanup_queue on other kind of block devices. I will try to put this cleanup as part of blk_cleanup_queue to see if it works.

Yeah that sounds right. This is due to elv-select.patch. Its quite a rats nest in there though :(

What should be happening is blk_alloc_queue should register the queue kobject, and blk_init_queue should allocate the the elevator kobject (which should be registered in the process).

add_disk should just be taking a reference on the queue, and add a symlink in sysfs to the real queue (I think). I have a patch to do this, but it is a bit ugly because I don't know where in sysfs to put the queue object.

Anyway, if this isn't going to be done before 2.6.0, I guess Andrew you should drop by elv-select patches for now. That doesn't fix anything, but it hides some of the problems.