Re: [PATCH v2 10/18] lib/stackdepot: rename handle and pool constants

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



+#define DEPOT_HANDLE_BITS (sizeof(depot_stack_handle_t) * 8)
+
+#define DEPOT_VALID_BITS 1
+#define DEPOT_POOL_ORDER 2 /* Pool size order, 4 pages */
+#define DEPOT_POOL_SIZE (1LL << (PAGE_SHIFT + DEPOT_POOL_ORDER))
+#define DEPOT_STACK_ALIGN 4
+#define DEPOT_OFFSET_BITS (DEPOT_POOL_ORDER + PAGE_SHIFT - DEPOT_STACK_ALIGN)
+#define DEPOT_POOL_INDEX_BITS (DEPOT_HANDLE_BITS - DEPOT_VALID_BITS - \
+			       DEPOT_OFFSET_BITS - STACK_DEPOT_EXTRA_BITS)
+#define DEPOT_POOLS_CAP 8192

Increase DEPOT_POOLS_CAP size to 32768

+#define DEPOT_MAX_POOLS \
+	(((1LL << (DEPOT_POOL_INDEX_BITS)) < DEPOT_POOLS_CAP) ? \
+	 (1LL << (DEPOT_POOL_INDEX_BITS)) : DEPOT_POOLS_CAP)


Hi Andrey.

I have some question about DEPOT_MAX_POOLS.
Actually I didn't know where to post my question, so here it is.
I'm testing a feature of the UFS4.0 specification called MCQ, 
the call stack looks like this and __stack_depot_save keeps printing warning messages.

[7:  OST-Normal-13:17476] ------------[ cut here ]------------
[7:  OST-Normal-13:17476] Stack depot reached limit capacity
[7:  OST-Normal-13:17476] pc : __stack_depot_save+0x464/0x46c
[7:  OST-Normal-13:17476] lr : __stack_depot_save+0x460/0x46c
[7:  OST-Normal-13:17476] sp : ffffffc008077730
[7:  OST-Normal-13:17476] x29: ffffffc008077750 x28: ffffffd00b78a000 x27: 0000000000000000
[7:  OST-Normal-13:17476] x26: 000000000009a7a4 x25: ffffff8914750000 x24: 000000004379a7a4
[7:  OST-Normal-13:17476] x23: 00000000000001f8 x22: 0000000000000210 x21: 000000000000003f
[7:  OST-Normal-13:17476] x20: ffffffc0080777b0 x19: 0000000000000000 x18: 0000000000001000
[7:  OST-Normal-13:17476] x17: 2065726568207475 x16: 00000000000000c3 x15: 2d2d2d2d2d2d2d20
[7:  OST-Normal-13:17476] x14: 5d36373437313a33 x13: 000000000059a740 x12: 000000000059a6f8
[7:  OST-Normal-13:17476] x11: 00000000ffffffff x10: ffffffb90aba9000 x9 : 008c3feffad60900
[7:  OST-Normal-13:17476] x8 : 008c3feffad60900 x7 : 000000000059a740 x6 : 000000000059a6f8
[7:  OST-Normal-13:17476] x5 : ffffffc008077438 x4 : ffffffd00b196970 x3 : ffffffd0092b313c
[7:  OST-Normal-13:17476] x2 : 0000000000000001 x1 : 0000000000000004 x0 : 0000000000000022
[7:  OST-Normal-13:17476] Call trace:
[7:  OST-Normal-13:17476]  __stack_depot_save+0x464/0x46c
[7:  OST-Normal-13:17476]  kasan_save_stack+0x58/0x70
[7:  OST-Normal-13:17476]  save_stack_info+0x34/0x138
[7:  OST-Normal-13:17476]  kasan_save_free_info+0x18/0x24
[7:  OST-Normal-13:17476]  ____kasan_slab_free+0x16c/0x170
[7:  OST-Normal-13:17476]  __kasan_slab_free+0x10/0x20
[7:  OST-Normal-13:17476]  kmem_cache_free+0x238/0x53c
[7:  OST-Normal-13:17476]  mempool_free_slab+0x1c/0x28
[7:  OST-Normal-13:17476]  mempool_free+0x7c/0x1a0
[7:  OST-Normal-13:17476]  sg_pool_free+0x6c/0x84
[7:  OST-Normal-13:17476]  __sg_free_table+0x88/0xbc
[7:  OST-Normal-13:17476]  sg_free_table_chained+0x40/0x4c
[7:  OST-Normal-13:17476]  scsi_free_sgtables+0x3c/0x7c
[7:  OST-Normal-13:17476]  scsi_mq_uninit_cmd+0x20/0x7c
[7:  OST-Normal-13:17476]  scsi_end_request+0xd8/0x304
[7:  OST-Normal-13:17476]  scsi_io_completion+0x88/0x160
[7:  OST-Normal-13:17476]  scsi_finish_command+0x17c/0x194
[7:  OST-Normal-13:17476]  scsi_complete+0xcc/0x158
[7:  OST-Normal-13:17476]  blk_mq_complete_request+0x4c/0x5c
[7:  OST-Normal-13:17476]  scsi_done_internal+0xf4/0x1e0
[7:  OST-Normal-13:17476]  scsi_done+0x14/0x20
[7:  OST-Normal-13:17476]  ufshcd_compl_one_cqe+0x578/0x71c
[7:  OST-Normal-13:17476]  ufshcd_mcq_poll_cqe_nolock+0xc8/0x150
[7:  OST-Normal-13:17476]  vendor_mcq_irq+0x74/0x88 [ufs-core]
[7:  OST-Normal-13:17476]  __handle_irq_event_percpu+0xd0/0x348
[7:  OST-Normal-13:17476]  handle_irq_event_percpu+0x24/0x74
[7:  OST-Normal-13:17476]  handle_irq_event+0x74/0xe0
[7:  OST-Normal-13:17476]  handle_fasteoi_irq+0x174/0x240
[7:  OST-Normal-13:17476]  handle_irq_desc+0x7c/0x2c0
[7:  OST-Normal-13:17476]  generic_handle_domain_irq+0x1c/0x28
[7:  OST-Normal-13:17476]  gic_handle_irq+0x64/0x158
[7:  OST-Normal-13:17476]  call_on_irq_stack+0x2c/0x54
[7:  OST-Normal-13:17476]  do_interrupt_handler+0x70/0xa0
[7:  OST-Normal-13:17476]  el1_interrupt+0x34/0x68
[7:  OST-Normal-13:17476]  el1h_64_irq_handler+0x18/0x24
[7:  OST-Normal-13:17476]  el1h_64_irq+0x68/0x6c
[7:  OST-Normal-13:17476]  __hwasan_check_x0_67043363+0xc/0x30
[7:  OST-Normal-13:17476]  ufshcd_queuecommand+0x5f8/0x7b4
[7:  OST-Normal-13:17476]  scsi_queue_rq+0xb88/0xea4
[7:  OST-Normal-13:17476]  blk_mq_dispatch_rq_list+0x640/0xe18
[7:  OST-Normal-13:17476]  blk_mq_do_dispatch_sched+0x47c/0x530
[7:  OST-Normal-13:17476]  __blk_mq_sched_dispatch_requests+0x158/0x1cc
[7:  OST-Normal-13:17476]  blk_mq_sched_dispatch_requests+0x68/0x9c
[7:  OST-Normal-13:17476]  __blk_mq_run_hw_queue+0x9c/0x11c
[7:  OST-Normal-13:17476]  __blk_mq_delay_run_hw_queue+0xa4/0x234
[7:  OST-Normal-13:17476]  blk_mq_run_hw_queue+0x130/0x150
[7:  OST-Normal-13:17476]  blk_mq_sched_insert_requests+0x208/0x3a0
[7:  OST-Normal-13:17476]  blk_mq_flush_plug_list+0x21c/0x4f0
[7:  OST-Normal-13:17476]  __blk_flush_plug+0x180/0x1d8
[7:  OST-Normal-13:17476]  blk_finish_plug+0x40/0x5c
[7:  OST-Normal-13:17476]  read_pages+0x420/0x4ac
[7:  OST-Normal-13:17476]  page_cache_ra_unbounded+0xec/0x288
[7:  OST-Normal-13:17476]  do_page_cache_ra+0x60/0x6c
[7:  OST-Normal-13:17476]  page_cache_ra_order+0x318/0x364
[7:  OST-Normal-13:17476]  do_sync_mmap_readahead+0x1a0/0x3c8
[7:  OST-Normal-13:17476]  filemap_fault+0x260/0x68c
[7:  OST-Normal-13:17476]  __do_fault+0x80/0x1b4
[7:  OST-Normal-13:17476]  handle_mm_fault+0x6b4/0x1530
[7:  OST-Normal-13:17476]  do_page_fault+0x3ec/0x5d4
[7:  OST-Normal-13:17476]  do_translation_fault+0x44/0x5c
[7:  OST-Normal-13:17476]  do_mem_abort+0x54/0xd8
[7:  OST-Normal-13:17476]  el0_ia+0x68/0xf4
[7:  OST-Normal-13:17476]  el0t_64_sync_handler+0xd0/0x114
[7:  OST-Normal-13:17476]  el0t_64_sync+0x190/0x194

After analyzing it, it seems that the stack buffer is running out of memory, 
so what do you think about increasing the size of DEPOT_POOLS_CAP to 32768?
Tell us, your opinion

Thanks.






[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [eCos]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux