> -----Original Message----- > From: Kent Overstreet <kent.overstreet@xxxxxxxxx> > Sent: Thursday, March 20, 2025 7:25 PM > To: Carlos Song <carlos.song@xxxxxxx> > Cc: surenb@xxxxxxxxxx; akpm@xxxxxxxxxxxxxxxxxxxx; willy@xxxxxxxxxxxxx; > linux-mm@xxxxxxxxx; linux-kernel@xxxxxxxxxxxxxxx; > linux-fsdevel@xxxxxxxxxxxxxxx > Subject: [EXT] Re: Ask help about this patch b951aaff5035 " mm: enable page > allocation tagging" > > Caution: This is an external email. Please take care when clicking links or > opening attachments. When in doubt, report the message using the 'Report this > email' button > > > On Thu, Mar 20, 2025 at 11:07:41AM +0000, Carlos Song wrote: > > Hi, all > > > > I found a 300ms~600ms IRQ off when writing 1Gb data to mmc device at > I.MX7d SDB board at Linux-kernel-v6.14. > > But I test the same case at Linux-kernel-v6.7, this longest IRQ off time is only > 1ms~2ms. So the issue is introduced from v6.7~v6.14. > > > > Run this cmd to test: > > dd if=/dev/zero of=/dev/mmcblk2p4 bs=4096 seek=12500 count=256000 > > conv=fsync > > > > This issue looks from blkdev_buffered_write() function. Because when I > > run this cmd with "oflag=direct" to use blkdev_direct_write(), I can not see > any long time IRQ off. > > > > Then I use Ftrace irqoff tracer to trace the longest IRQ off event, I found some > differences between v6.7 and v6.14: > > In iomap_file_buffered_write(), __folio_alloc (in v6.7) is replaced by > _folio_alloc_noprof (in v6.14) by this patch. > > The spinlock disabled IRQ ~300ms+. It looks there are some fixes for this patch, > but I still can see IRQ off 300ms+ at 6.14.0-rc7-next-20250319. > > > > Do I trigger one bug? I know little about mem so I have to report it and hope I > can get some help or guide. > > I put my ftrace log at the mail tail to help trace and explain. > > Did you track down which spinlock? > > > Hi, Sorry for my late reply and thank you for your quick reply!
