Skip to contentSkip to conversation

Linux 2.4.18-pre9-mjc2

DISCUSSION Michael Cohen 13 participants 23 messages Feb 14, 2002 – Mar 1, 2002

lore
Share & tools
lore
#0 lore raw

The latest version of the -mjc branch has been released. It is available at:

	ftp://ftp.kernel.org/pub/linux/kernel/people/mjc/linux-2.4/patch-2.4.18-pre9-mjc2.bz2

--------------------------------------------------------------
[ A great deal of patches have been removed, in interest of keeping this branch as close to the standard 2.4 series as possible.]
[ I am now using bitkeeper, and my bk tree is available at bk://ohdarn.net/linux-mjc. it is cloned from linus's 2.4 tree so please, please, please clone from him and pull from me. ]

2.4.18-pre9-ac3 (Alan Cox et al)
Reverse Mapping VM Patch #12e (Rik van Riel)
O(1) Scheduler K3 (Ingo Molnar)
IRQrate (IM)
Preemptible Kernel Patch (Robert M. Love)
Break Selected Locks (RML)
Netdev-Random (RML)
Fibonacci Hashing: (prime for 32-bit) (William Lee Irwin III)
-Inode hash (WLI)
-Page cache hash (WLI)
-UID hash (dynamic) (WLI)
-PID hash (dynamic) (WLI)
OOM trigger increase (WLI)
Change VM policy to overcommit (WLI)
Page aging adjustments (WLI)
Netfilter Header Order Fix (WLI)
proc_pid_statm() cleanup (WLI)
task_nice export (WLI)
Bootmem Rewrite (WLI)
Mountcache size reduction (WLI, Andi Kleen, Al Viro)
Slab search optimization (Momchil Velikov)
Radix tree page cache search (MV)
UserMode Linux (Jeff Dike)
Loop Mounting Deadlock Fix (Andrew Morton)
Read Latency Fix #2 (AKPM)
CDDA DMA fix (AKPM)
82Cxx devexit (AKPM)
make request (AKPM)
slab cache estimate optimization (Balbir Singh)
x86 Syscall stall fix (Alexander Khripin)
Bdflush parameters (Stephen van der Krantz)
AMD Elan Updates (Robert Schwiebel)
SiS5513 updates (20020128_1) (Daniel Bouton)
lm_sensors (lm_sensors team)
Verbose BUG() (Hugh Dickins)
Xconfig help fix (Olaf Diestche)
V4L2 (V4L2 Team)
SCSI CD Changer (?)

------
Michael J. Cohen
OhDarn.net

#1 lore raw
Quoted 1 line

SiS5513 updates (20020128_1) (Daniel Bouton)

Erm, make that Lionel Bouton. My apologies. :)

-----
Michael Cohen
OhDarn.net

#2 lore raw
In reply to Michael Cohen
Quoted 1 line

Reverse Mapping VM Patch #12e (Rik van Riel)

Except that Documentation/vm/Changelog.rmap still reports...

rmap 12a:

  - fix the compile warning in buffer.c                   (me)
  - fix divide-by-zero on highmem initialisation  DOH!    (me)
  - remove the pgd quicklist (suspicious ...)             (DaveM, me)

This is confusing to people. is 12e applied??

--

Andrew Hatfield
SecureONE - http://www.secureone.com.au/
President - South East Brisbane Linux Users Group http://www.seblug.org/

Kernel work available at http://development.secureone.com.au/kernel/

#3 lore raw
In reply to Michael Cohen
Quoted 3 lines · Michael Cohen

[ I am now using bitkeeper, and my bk tree is available at bk://ohdarn.net/linux-mjc. it is cloned from linus's 2.4 tree so please, please, please clone from him and pull from me. ]

Just in case people need a reminder, you would do this:

bk clone bk://linux.bkbits.net/linux-2.4
cd linux-2.4
bk pull bk://ohdarn.net/linux-mjc

This means you use our bandwidth for the main clone and then only take updates from Michael.

Michael, if you want to stash a mirror here, that's easy, take a look at

http://www.bitkeeper.com/Hosted.html

it should be pretty straight forward.

Cheers,

Signature · 2 lines
---
Larry McVoy            	 lm at bitmover.com           http://www.bitmover.com/lm 
#4 lore raw
In reply to Michael Cohen

got this problem when applying 2.4.18-pre8-mjc to 2.4.18-pre8 to 2.4.17 as well as newly released 2.4.18-pre8-mjc2

filemap.c: In function `__find_page_nolock':
filemap.c:404: structure has no member named `next_hash'

Not sure if this is related to Rik's rmap patch or Ingo's O(1) Scheduler patch (or again, something else entirely)

your mjc2 patch contains....
patch-2.4.18-pre9-mjc2:- struct page *next_hash; /* Next page
sharing our hash bucket in
patch-2.4.18-pre9-mjc2:- struct page **pprev_hash; /*
Complement to *next_hash. */

which modifes linux/include/linux/mm.h

if i comment out the line in filemap.c it continues to compile... until problems with ip.h (more to come)

--

Andrew Hatfield
SecureONE - http://www.secureone.com.au/
President - South East Brisbane Linux Users Group http://www.seblug.org/

Kernel work available at http://development.secureone.com.au/kernel/

#5 lore raw

Correct fix is to remove __find_page_nolock entirely.

Quoted 36 lines · Andrew Hatfield

got this problem when applying 2.4.18-pre8-mjc to 2.4.18-pre8 to 2.4.17 as well as newly released 2.4.18-pre8-mjc2

filemap.c: In function `__find_page_nolock':
filemap.c:404: structure has no member named `next_hash'

Not sure if this is related to Rik's rmap patch or Ingo's O(1) Scheduler patch (or again, something else entirely)

your mjc2 patch contains....
patch-2.4.18-pre9-mjc2:- struct page *next_hash; /* Next page
sharing our hash bucket in
patch-2.4.18-pre9-mjc2:- struct page **pprev_hash; /*
Complement to *next_hash. */

which modifes linux/include/linux/mm.h

if i comment out the line in filemap.c it continues to compile... until problems with ip.h (more to come)

--

Andrew Hatfield
SecureONE - http://www.secureone.com.au/
President - South East Brisbane Linux Users Group http://www.seblug.org/

Kernel work available at http://development.secureone.com.au/kernel/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

#6 lore raw
In reply to Michael Cohen
Quoted 6 lines · Andrew Hatfield

got this problem when applying 2.4.18-pre8-mjc to 2.4.18-pre8 to 2.4.17 as well as newly released 2.4.18-pre8-mjc2
filemap.c: In function `__find_page_nolock':
filemap.c:404: structure has no member named `next_hash'
Not sure if this is related to Rik's rmap patch or Ingo's O(1) Scheduler patch (or again, something else entirely)

Quoted 8 lines

your mjc2 patch contains....
patch-2.4.18-pre9-mjc2:- struct page *next_hash; /* Next page
sharing our hash bucket in
patch-2.4.18-pre9-mjc2:- struct page **pprev_hash; /*
Complement to *next_hash. */
which modifes linux/include/linux/mm.h
if i comment out the line in filemap.c it continues to compile... until problems with ip.h (more to come)

It contains the ratcache by Momchil Velikov which eliminates the need for those fields within struct page.
This is not the fix you're looking for...

Cheers,
Bill

#7 lore raw
In reply to Michael Cohen
Quoted 3 lines · Michael Cohen
Quoted 1 line

SiS5513 updates (20020128_1) (Daniel Bouton)

Erm, make that Lionel Bouton. My apologies. :)

No problem.
But 20020128_1 has buggy chip capability detection code for most chipsets. 20020214_1 solves this (mostly, it doesn't work yet for chip not in the in-driver database).

LB.

#8 lore raw
In reply to Michael Cohen
Quoted 1 line · Michael Cohen

2.4.18-pre9-ac3 (Alan Cox et al)

...

Quoted 1 line

lm_sensors (lm_sensors team)

Hum, the last time I merged that stuff into my own kernel, the patch-generator that they ship did not include all of the drivers I needed. Also, I'm missing i2c from your patch list. Is that intentional or is the i2c patch not needed? Which lm_sensors version did you merge?

Signature · 4 lines
Matthias Andree

"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."         Benjamin Franklin
#9 lore raw
Quoted 6 lines
Quoted 1 line

lm_sensors (lm_sensors team)

Hum, the last time I merged that stuff into my own kernel, the patch-generator that they ship did not include all of the drivers I needed. Also, I'm missing i2c from your patch list. Is that intentional or is the i2c patch not needed? Which lm_sensors version did you merge?

Be very careful merging lm_sensors. Incorrect use of it is a wonderful way to do things like totally destroy (back to factory) an ibm thinkpad. Thats why I've always stayed clear of it

#10 lore raw
Quoted 11 lines · Alan Cox
Quoted 7 lines
Quoted 2 lines

lm_sensors (lm_sensors team)

Hum, the last time I merged that stuff into my own kernel, the patch-generator that they ship did not include all of the drivers I needed. Also, I'm missing i2c from your patch list. Is that intentional or is the i2c patch not needed? Which lm_sensors version did you merge?

Be very careful merging lm_sensors. Incorrect use of it is a wonderful way to do things like totally destroy (back to factory) an ibm thinkpad.

Well that is only one single sensor driver... The rest work's rather nicely.

#11 lore raw
In reply to Matthias Andree

Hi!

Quoted 8 lines
Quoted 4 lines

Hum, the last time I merged that stuff into my own kernel, the patch-generator that they ship did not include all of the drivers I needed. Also, I'm missing i2c from your patch list. Is that intentional or is the i2c patch not needed? Which lm_sensors version did you merge?

Be very careful merging lm_sensors. Incorrect use of it is a wonderful way to do things like totally destroy (back to factory) an ibm thinkpad. Thats why I've always stayed clear of it

They deserve it! Shipping hardware that commits suicide on i2o access is bad thing (tm).
Pavel

Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt,
details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
#12 lore raw
Quoted 6 lines
Quoted 3 lines

Be very careful merging lm_sensors. Incorrect use of it is a wonderful way to do things like totally destroy (back to factory) an ibm thinkpad. Thats why I've always stayed clear of it

They deserve it! Shipping hardware that commits suicide on i2c access is bad thing (tm).

IBM don't replace machines where you do that. So I suspect you'll have a few users with very different views on the matter.

#13 lore raw
In reply to Pavel Machek

Hi!

Quoted 9 lines
Quoted 6 lines
Quoted 3 lines

Be very careful merging lm_sensors. Incorrect use of it is a wonderful way to do things like totally destroy (back to factory) an ibm thinkpad. Thats why I've always stayed clear of it

They deserve it! Shipping hardware that commits suicide on i2c access is bad thing (tm).

IBM don't replace machines where you do that. So I suspect you'll have a few users with very different views on the matter.

Someone should buy thinkpad, destroy it (preferably with CD labeled Virus 98 or soemthing like that), return, destroy next, return, destroy next, request money back.

Alternatively make a virus that destroys thinkpads -- should make them some bad press, too.
Pavel

Signature · 2 lines
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
#14 lore raw
Quoted 3 lines

Someone should buy thinkpad, destroy it (preferably with CD labeled Virus 98 or soemthing like that), return, destroy next, return, destroy next, request money back.

If you want to get arrested it sounds a great idea. Thats up to you

Quoted 2 lines

Alternatively make a virus that destroys thinkpads -- should make them some bad press, too.

A virus to destroy any PC is trivial. Just be thankful nobody has crossed the really infectious ones with stuff like chernobyl and disk firmware erasers.

The PC simply is not a secure platform

#15 lore raw
In reply to Pavel Machek

Hi!

Quoted 5 lines
Quoted 3 lines

Someone should buy thinkpad, destroy it (preferably with CD labeled Virus 98 or soemthing like that), return, destroy next, return, destroy next, request money back.

If you want to get arrested it sounds a great idea. Thats up to you

Huh? They are shipping faulty products. Unless their manual say "you are only allowed to run windows 95 release 1, Word version 3.71 and Outlook 17.32 and nothing else, you have handled your computer properly and its *their* problem.

Quoted 6 lines
Quoted 2 lines

Alternatively make a virus that destroys thinkpads -- should make them some bad press, too.

A virus to destroy any PC is trivial. Just be thankful nobody has crossed the really infectious ones with stuff like chernobyl and disk firmware erasers.

What did chernobyl do? I've never seen PC damaged beyond repair. Everyone with a clue has jumper on stuff like flashing, and I can imagine that opening the case can void your warranty.
Pavel

Signature · 2 lines
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
#16 lore raw
Quoted 6 lines
Quoted 1 line

If you want to get arrested it sounds a great idea. Thats up to you

Huh? They are shipping faulty products. Unless their manual say "you are only allowed to run windows 95 release 1, Word version 3.71 and Outlook 17.32 and nothing else, you have handled your computer properly and its *their* problem.

You didnt handle it properly. You'll find the old "you cannot damage the computer" messages vanished about the time of the IBM/AT. You instructed it to erase critical internal data, so it did.

Quoted 1 line

What did chernobyl do? I've never seen PC damaged beyond

Erased the bios

Quoted 2 lines

repair. Everyone with a clue has jumper on stuff like flashing, and I can imagine that opening the case can void your warranty.

You don't however have a jumper to protect your disk firmware do you...

#17 lore raw

man, 2002-02-18 kl. 22:39 skrev Alan Cox:

Quoted 11 lines
Quoted 6 lines
Quoted 1 line

If you want to get arrested it sounds a great idea. Thats up to you

Huh? They are shipping faulty products. Unless their manual say "you are only allowed to run windows 95 release 1, Word version 3.71 and Outlook 17.32 and nothing else, you have handled your computer properly and its *their* problem.

You didnt handle it properly. You'll find the old "you cannot damage the computer" messages vanished about the time of the IBM/AT. You instructed it to erase critical internal data, so it did.

Quoted 9 lines
Quoted 1 line

What did chernobyl do? I've never seen PC damaged beyond

Erased the bios

Quoted 2 lines

repair. Everyone with a clue has jumper on stuff like flashing, and I can imagine that opening the case can void your warranty.

You don't however have a jumper to protect your disk firmware do you...

And you don't have a jumper on most laptops I've seen - neither do you want to disassemble the laptop every time you decide to upgrade the BIOS (at least I know I don't).

I've also seen lots of PCs that do exactly things like flashing the BIOS during the first install cycle after you power up. I've even had to return one because of user intervention (some guy flicked the power during BIOS upgrade...)

Cheers
Kjartan

#18 lore raw
In reply to Pavel Machek

Hi!

Quoted 10 lines
Quoted 6 lines
Quoted 1 line

If you want to get arrested it sounds a great idea. Thats up to you

Huh? They are shipping faulty products. Unless their manual say "you are only allowed to run windows 95 release 1, Word version 3.71 and Outlook 17.32 and nothing else, you have handled your computer properly and its *their* problem.

You didnt handle it properly. You'll find the old "you cannot damage the computer" messages vanished about the time of the IBM/AT. You instructed it to erase critical internal data, so it did.

I asked it to read temperature sensors *then* it commited suicide.

I believe consumer protection laws require manual to be shipped with a product, and manual should state how you should handle your computer. Unless they say "never run anything you downloaded", they should return your machine.

Quoted 5 lines
Quoted 2 lines

repair. Everyone with a clue has jumper on stuff like flashing, and I can imagine that opening the case can void your warranty.

You don't however have a jumper to protect your disk firmware do you...

In such case disk should either:

*) have "firmware flasher" part unwritable,

or

*) check signature on whatever it is flashing in, and if it does not match, refuse to flash it.

Signature · 2 lines
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.
#19 lore raw
Quoted 4 lines
Quoted 2 lines

computer" messages vanished about the time of the IBM/AT. You instructed it to erase critical internal data, so it did.

I asked it to read temperature sensors *then* it commited suicide.

No. You load lm_sensors, it does a bus scan and that trashes your eeprom. Its an lm_sensors problem (but rather hard to avoid when poking around randomly inside a laptop without a clue what its doing)

Quoted 5 lines

In such case disk should either:
*) have "firmware flasher" part unwritable,
or
*) check signature on whatever it is flashing in, and if it does not match, refuse to flash it.

Well they don't.

#20 lore raw
In reply to Pavel Machek

Hi!

Quoted 8 lines
Quoted 4 lines
Quoted 2 lines

computer" messages vanished about the time of the IBM/AT. You instructed it to erase critical internal data, so it did.

I asked it to read temperature sensors *then* it commited suicide.

No. You load lm_sensors, it does a bus scan and that trashes your eeprom. Its an lm_sensors problem (but rather hard to avoid when poking around randomly inside a laptop without a clue what its doing)

Okay, so what about adding dmi _white_list to lm_sensors? That should address your concerns... [It would also be possible to autosetup temperature offsets/divisors etc.]
Pavel

Signature · 2 lines
(about SSSCA) "I don't say this lightly.  However, I really think that the U.S.
no longer is classifiable as a democracy, but rather as a plutocracy." --hpa
#21 lore raw
In reply to Michael Cohen
Quoted 10 lines · Larry McVoy
Quoted 3 lines · Michael Cohen

[ I am now using bitkeeper, and my bk tree is available at bk://ohdarn.net/linux-mjc. it is cloned from linus's 2.4 tree so please, please, please clone from him and pull from me. ]

Just in case people need a reminder, you would do this:

bk clone bk://linux.bkbits.net/linux-2.4
cd linux-2.4
bk pull bk://ohdarn.net/linux-mjc

oscar% bk clone -q linux-2.4 linux-mjc-edt
oscar% cd linux-mjc-edt
oscar% bk pull bk://ohdarn.net/linux-mjc
Nothing to pull from bk://ohdarn.net/linux-mjc
oscar%

Where linux-2.4 is a local clone of linux-2.4. Why does it find nothing to pull ?

TIA
Ed Tomlinson

#22 lore raw

Re: Linux 2.4.18-pre9-mjc2 & Rmap12f [PATCH]

In reply to Michael Cohen
Quoted 11 lines · Michael Cohen

The latest version of the -mjc branch has been released. It is available at:

	ftp://ftp.kernel.org/pub/linux/kernel/people/mjc/linux-2.4/patch-2.4.18-pre9-mjc2.bz2

--------------------------------------------------------------
[ A great deal of patches have been removed, in interest of keeping this branch as close to the standard 2.4 series as possible.]
[ I am now using bitkeeper, and my bk tree is available at bk://ohdarn.net/linux-mjc. it is cloned from linus's 2.4 tree so please, please, please clone from him and pull from me. ]

Quoted 2 lines

2.4.18-pre9-ac3 (Alan Cox et al)
Reverse Mapping VM Patch #12e (Rik van Riel)

Here's rmap12f:

I'm not sure I murged mm/bootmem.c correctly, can someone take a look?

Makefile +1 -1
diff -ur 2.4.18-pre9-mjc2/Makefile 2.4.18-pre9-mjc2-rmap12f/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 4
 SUBLEVEL = 18
-EXTRAVERSION = -pre9-mjc2
+EXTRAVERSION = -pre9-mjc2-rmap12f
 
 KERNELRELEASE=$(VERSION).$(PATCHLEVEL).$(SUBLEVEL)$(EXTRAVERSION)
 
fs/buffer.c +1 -0
diff -ur 2.4.18-pre9-mjc2/fs/buffer.c 2.4.18-pre9-mjc2-rmap12f/fs/buffer.c
@@ -2991,6 +2991,7 @@
 
 		spin_lock(&lru_list_lock);
 		if (!write_some_buffers(NODEV) || balance_dirty_state() < 0) {
+			run_task_queue(&tq_disk);
 			interruptible_sleep_on(&bdflush_wait);
 		}
 	}
include/linux/mmzone.h +15 -0
diff -ur 2.4.18-pre9-mjc2/include/linux/mmzone.h 2.4.18-pre9-mjc2-rmap12f/include/linux/mmzone.h
@@ -161,6 +161,21 @@
 
 extern pg_data_t contig_page_data;
 
+/**
+ * for_each_pgdat - helper macro to iterate over all nodes
+ * @pgdat - pg_data_t * variable
+ *
+ * Meant to help with common loops of the form
+ * pgdat = pgdat_list;
+ * while(pgdat) {
+ * 	...
+ * 	pgdat = pgdat->node_next;
+ * }
+ */
+#define for_each_pgdat(pgdat) \
+		for (pgdat = pgdat_list; pgdat; pgdat = pgdat->node_next)
+
+
 /*
  * next_zone - helper magic for for_each_zone()
  * Thanks to William Lee Irwin III for this piece of ingenuity.
kernel/ksyms.c +1 -0
diff -ur 2.4.18-pre9-mjc2/kernel/ksyms.c 2.4.18-pre9-mjc2-rmap12f/kernel/ksyms.c
@@ -251,6 +251,7 @@
 EXPORT_SYMBOL(__pollwait);
 EXPORT_SYMBOL(poll_freewait);
 EXPORT_SYMBOL(ROOT_DEV);
+EXPORT_SYMBOL(__find_get_page);
 EXPORT_SYMBOL(find_get_page);
 EXPORT_SYMBOL(find_lock_page);
 EXPORT_SYMBOL(grab_cache_page);
mm/bootmem.c +1 -3
diff -ur 2.4.18-pre9-mjc2/mm/bootmem.c 2.4.18-pre9-mjc2-rmap12f/mm/bootmem.c
@@ -897,13 +897,11 @@
 	pg_data_t *pgdat = pgdat_list;
 	void *ptr;
 
-	while (pgdat) {
+	for_each_pgdat(pgdat) {
 		ptr = __alloc_bootmem_core(pgdat->bdata, size, align, goal);
 
 		if(ptr)
 			return ptr;
-
-		pgdat = pgdat->node_next;
 	}
 
 	printk(KERN_ALERT "bootmem alloc of %lu bytes failed!\n", size);
mm/page_alloc.c +9 -14
diff -ur 2.4.18-pre9-mjc2/mm/page_alloc.c 2.4.18-pre9-mjc2-rmap12f/mm/page_alloc.c
@@ -627,14 +627,11 @@
 {
 	unsigned int sum;
 	zone_t *zone;
-	pg_data_t *pgdat = pgdat_list;
 
 	sum = 0;
-	while (pgdat) {
-		for (zone = pgdat->node_zones; zone < pgdat->node_zones + MAX_NR_ZONES; zone++)
-			sum += zone->free_pages;
-		pgdat = pgdat->node_next;
-	}
+	for_each_zone(zone)
+		sum += zone->free_pages;
+	
 	return sum;
 }
 
@@ -643,10 +640,10 @@
  */
 unsigned int nr_free_buffer_pages (void)
 {
-	pg_data_t *pgdat = pgdat_list;
+	pg_data_t *pgdat;
 	unsigned int sum = 0;
 
-	do {
+	for_each_pgdat(pgdat) {
 		zonelist_t *zonelist = pgdat->node_zonelists + (GFP_USER & GFP_ZONEMASK);
 		zone_t **zonep = zonelist->zones;
 		zone_t *zone;
@@ -657,8 +654,7 @@
 			sum += zone->inactive_dirty_pages;
 		}
 
-		pgdat = pgdat->node_next;
-	} while (pgdat);
+	}
 
 	return sum;
 }
@@ -666,13 +662,12 @@
 #if CONFIG_HIGHMEM
 unsigned int nr_free_highpages (void)
 {
-	pg_data_t *pgdat = pgdat_list;
+	pg_data_t *pgdat;
 	unsigned int pages = 0;
 
-	while (pgdat) {
+	for_each_pgdat(pgdat)
 		pages += pgdat->node_zones[ZONE_HIGHMEM].free_pages;
-		pgdat = pgdat->node_next;
-	}
+
 	return pages;
 }
 #endif
mm/vmscan.c +4 -0
diff -ur 2.4.18-pre9-mjc2/mm/vmscan.c 2.4.18-pre9-mjc2-rmap12f/mm/vmscan.c
@@ -652,6 +652,10 @@
 
 	refill_freelist();
 
+	/* Start IO when needed. */
+	if (free_plenty(ALL_ZONES) > 0 || free_low(ANY_ZONE) > 0)
+		run_task_queue(&tq_disk);
+
 	/*
 	 * Hmm.. Cache shrink failed - time to kill something?
 	 * Mhwahahhaha! This is the part I really like. Giggle.