Messages in this thread Patch in this message | | | Subject | Re: vhand-2.1.64... problems solved - but not all ;) | From | Zlatko Calusic <> | Date | 20 Nov 1997 15:48:38 +0100 |
| |
crosser@average.org (Eugene Crosser) writes:
> [Posted and mailed] > > Rik, > > just to let you know. For me, all 2.1.xx kernels are hanging trying > to allocate TCP buffers (I reported this problem), and I tried vhand > patch in the hope that it may help, as it deals with memory management. > > Unfortunately, it did not. I got the system hung with the same > symptoms in less then 24 hours uptime. Also, perfomance of cpu > intensive applications (mpg123) dropped noticably with vhand. > > I have a 120MHz 486dx4 w/16Mb, kernel 2.1.63+vhand-2.1.63. > > BTW, Zlatko's patch seemed to cure the hang problem, but after a few > days, the system freezed anyway at the same place. >
Hi!
Please apply this small patch and see if it solves your problems. It definitely solved mine. :)
Regards,
diff -urbBN --exclude-from=exclude linux/mm/slab.c /usr/src/linux/mm/slab.c --- linux/mm/slab.c Thu Aug 14 05:03:22 1997 +++ /usr/src/linux/mm/slab.c Fri Nov 14 07:44:44 1997 @@ -308,12 +308,12 @@ #define SLAB_MAX_GFP_ORDER 5 /* 32 pages */ /* the 'prefered' minimum num of objs per slab - maybe less for large objs */ -#define SLAB_MIN_OBJS_PER_SLAB 4 +#define SLAB_MIN_OBJS_PER_SLAB 1 /* If the num of objs per slab is <= SLAB_MIN_OBJS_PER_SLAB, * then the page order must be less than this before trying the next order. */ -#define SLAB_BREAK_GFP_ORDER 2 +#define SLAB_BREAK_GFP_ORDER 1 /* Macros for storing/retrieving the cachep and or slab from the * global 'mem_map'. With off-slab bufctls, these are used to find the -- Posted by Zlatko Calusic E-mail: <Zlatko.Calusic@CARNet.hr> --------------------------------------------------------------------- No sense being pessimistic. It wouldn't work anyway.
| |