Hi Shailabh,
In my Fedora Core 2 (1.521) based 2.6.8 kernel I am seeing the "sleeping function called from invalid context" problem that I reported before. Below is the calltrace. As you can see, it appears to be coming from the call to mempool_alloc in your version of cfq_get_queue. Maybe it is necessary to specify a different GFP value in my FC2 kernel?! I suppose this is on my plate to fix, as you do not see this in your vanilla 2.6.8.1 kernel, right?
No, I don't.
This cfq-iosched.c appears to be buggy. In vanilla 2.6.8.1, the cfq-iosched.c has the following change to the mempool code:
if (gfp_mask & __GFP_WAIT) {
spin_unlock_irq(q->queue_lock);
new_cfqq = mempool_alloc(cfq_mpool, gfp_mask);
spin_lock_irq(q->queue_lock);
goto retry;So we'd need to do something similar (unlock the request queue before
allocating). Problem is that we don't have easy access to the request queue in our version....let me rustle up a patch which should fix that.
Perhaps I should just bite the bullet and separate the "io priority addition" parts of our cfq-iosched.c out. That'll help us take advantage of other bug fixes. Let me see - I'll put out a hack first.
-- Shailabh
Sep 23 10:05:59 mef-work-laptop kernel: Debug: sleeping function called from invalid context at mm/mempool.c:197 Sep 23 10:05:59 mef-work-laptop kernel: in_atomic():0[expected: 0], irqs_disabled():1 Sep 23 10:05:59 mef-work-laptop kernel: [<02114e4c>] __might_sleep+0x82/0x8c Sep 23 10:05:59 mef-work-laptop kernel: [<02145606>] mempool_alloc+0x68/0x237 Sep 23 10:05:59 mef-work-laptop kernel: [<021155ff>] autoremove_wake_function+0x0/0x2d Sep 23 10:05:59 mef-work-laptop kernel: [<02145617>] mempool_alloc+0x79/0x237 Sep 23 10:05:59 mef-work-laptop kernel: [<021155ff>] autoremove_wake_function+0x0/0x2d Sep 23 10:05:59 mef-work-laptop kernel: [<02213992>] cfq_get_queue+0x4c/0xac Sep 23 10:05:59 mef-work-laptop kernel: [<02213a18>] __cfq_enqueue+0x26/0x141 Sep 23 10:05:59 mef-work-laptop kernel: [<02213bbc>] cfq_enqueue+0x31/0x63 Sep 23 10:05:59 mef-work-laptop kernel: [<02209f36>] __elv_add_request+0x35/0x6a Sep 23 10:05:59 mef-work-laptop kernel: [<0220ce1e>] __make_request+0x51c/0x5d4 Sep 23 10:05:59 mef-work-laptop kernel: [<0220d062>] generic_make_request+0x18c/0x19c Sep 23 10:05:59 mef-work-laptop kernel: [<0220d116>] submit_bio+0xa4/0xac Sep 23 10:05:59 mef-work-laptop kernel: [<0214e1b6>] __pagevec_lru_add+0x1b5/0x1c1 Sep 23 10:05:59 mef-work-laptop kernel: [<02190c16>] mpage_bio_submit+0x18/0x1b Sep 23 10:05:59 mef-work-laptop kernel: [<0219114b>] mpage_readpages+0xf2/0xfc Sep 23 10:05:59 mef-work-laptop kernel: [<0214686c>] __rmqueue+0xbb/0x10a Sep 23 10:05:59 mef-work-laptop kernel: [<021b31c5>] ext3_readpages+0x12/0x14 Sep 23 10:05:59 mef-work-laptop kernel: [<021b267b>] ext3_get_block+0x0/0x6c Sep 23 10:05:59 mef-work-laptop kernel: [<02149a8a>] read_pages+0x33/0xdd Sep 23 10:05:59 mef-work-laptop kernel: [<02146c93>] buffered_rmqueue+0x1e9/0x20c Sep 23 10:05:59 mef-work-laptop kernel: [<02146f6a>] __alloc_pages+0x2b4/0x2be Sep 23 10:05:59 mef-work-laptop kernel: [<0214a0f0>] do_page_cache_readahead+0x29f/0x2bf Sep 23 10:05:59 mef-work-laptop kernel: [<02143b64>] filemap_nopage+0x133/0x2bf Sep 23 10:05:59 mef-work-laptop kernel: [<02154db4>] do_no_page+0xfb/0x4ce Sep 23 10:05:59 mef-work-laptop kernel: [<0215537e>] handle_mm_fault+0xe5/0x21f Sep 23 10:05:59 mef-work-laptop kernel: [<021117b2>] do_page_fault+0x16b/0x489 Sep 23 10:05:59 mef-work-laptop kernel: [<02156538>] __vma_link+0x59/0x66 Sep 23 10:05:59 mef-work-laptop kernel: [<02156657>] vma_link+0x112/0x225 Sep 23 10:05:59 mef-work-laptop kernel: [<021587a4>] do_brk+0x317/0x41a Sep 23 10:05:59 mef-work-laptop kernel: [<0229f947>] __cond_resched+0x14/0x3b Sep 23 10:05:59 mef-work-laptop kernel: [<02111647>] do_page_fault+0x0/0x489
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Shailabh Nagar Sent: Tuesday, September 21, 2004 7:00 PM To: Marc Fiuczynski Cc: ckrm-tech Subject: [ckrm-tech] I/O controller for e16
Here is another attempt to get the I/O controller working for e16.
On my P4 SMT box, I'm able to run tiobench's in different classes though I don't observe a significant differentiation between the priority levels. OTOH, the depth of the I/O request queues formed by tiobench is pretty small so that needs to be eliminated as a cause by using an aio-based test.
Please give it a spin. There's rudimentary documentation included in the patch.
Marc, I'm getting onto the differentiation resolution now. Let me know if this controller creates problems like last time...
Regards, Shailabh
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
------------------------------------------------------- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
