On Tue, Jan 25, 2022 at 04:29:37PM +0000, Martin Wilck wrote: > On Wed, 2022-01-12 at 17:59 +0100, Martin Wilck wrote: > > On Mon, 2022-01-10 at 10:59 +0800, Ming Lei wrote: > > > > > > Hello Martin Wilck, > > > > > > Can you test the following change and report back the result? > > > > > > From 480a61a85e9669d3487ebee8db3d387df79279fc Mon Sep 17 00:00:00 > > > 2001 > > > From: Ming Lei <ming.lei@xxxxxxxxxx> > > > Date: Mon, 10 Jan 2022 10:26:59 +0800 > > > Subject: [PATCH] scsi: core: reallocate scsi device's budget map if > > > default > > > queue depth is changed > > > > > > Martin reported that sdev->queue_depth can often be changed in > > > ->slave_configure(), and now we uses ->cmd_per_lun as initial queue > > > depth for setting up sdev->budget_map. And some extreme - > > > >cmd_per_lun > > > or ->can_queue won't be used at default actually, if we they are > > > used > > > to allocate sdev->budget_map, huge memory may be consumed just > > > because > > > of bad ->cmd_per_lun. > > > > > > Fix the issue by reallocating sdev->budget_map after - > > > > slave_configure() > > > returns, at that time, queue_depth should be much more reasonable. > > > > > > Reported-by: Martin Wilck <martin.wilck@xxxxxxxx> > > > Suggested-by: Martin Wilck <martin.wilck@xxxxxxxx> > > > Signed-off-by: Ming Lei <ming.lei@xxxxxxxxxx> > > > > This looks good. I added a few pr_infos, and for the strange mpt3sas > > devices I reported, I get this: > > > > # first allocation with depth=7 (cmds_per_lun) > > Jan 12 17:05:52 localhost kernel: scsi_realloc_sdev_budget_map: 7 0- > > >0 > > (these numbers are: depth old_shift->new_shift) > > Jan 12 17:05:52 localhost kernel: scsi_realloc_sdev_budget_map: > > map_nr = 1024 > > > > # after slave_alloc() with depth 254 > > Jan 12 17:05:52 localhost kernel: scsi_realloc_sdev_budget_map: 254 > > 0->5 > > Jan 12 17:05:52 localhost kernel: scsi_realloc_sdev_budget_map: > > map_nr = 32 > > > > So the depth changed from 7 to 254, the shift from 0 to 5, and the > > memory size of the > > sbitmap was reduced by a factor of 32. Nice! > > > > Tested-by: Martin Wilck <mwilck@xxxxxxxx> > > Reviewed-by: Martin Wilck <mwilck@xxxxxxxx> > > So, how do we proceed with this patch? Looks 5.18/scsi is open now, I will submit one formal patch on linux-scsi soon. Thanks, Ming
