I am sorry to say this but I get those OOMs even with your patch.
I have 48M RAM on this P133 and all I have to do is to dd 2 22M files to
/dev/ram0 and /dev/ram1 respectiely. This is on
2.3.35-pre6 + your patch below.
Regards,
Tigran.
On Mon, 27 Dec 1999, Andrea Arcangeli wrote:
> On Sun, 26 Dec 1999, Tigran Aivazian wrote:
>
> >how to not OOM while protecting too many buffers...
>
> A workaround for a production 2.2.x is:
>
> echo 4 >/proc/sys/vm/bdflush
>
> The right fix should looks like the below patch:
>
> --- 2.3.35pre4-ramdisk-oom/fs/buffer.c.~1~ Fri Dec 24 02:00:56 1999
> +++ 2.3.35pre4-ramdisk-oom/fs/buffer.c Mon Dec 27 00:24:37 1999
> @@ -818,7 +818,8 @@
> {
> unsigned long dirty, tot, hard_dirty_limit, soft_dirty_limit;
>
> - dirty = size_buffers_type[BUF_DIRTY] >> PAGE_SHIFT;
> + dirty = size_buffers_type[BUF_DIRTY]+size_buffers_type[BUF_PROTECTED];
> + dirty >>= PAGE_SHIFT;
> tot = nr_free_buffer_pages();
> hard_dirty_limit = tot * bdf_prm.b_un.nfract / 100;
> soft_dirty_limit = hard_dirty_limit >> 1;
> @@ -871,6 +872,8 @@
> dispose = BUF_LOCKED;
> if (buffer_dirty(bh))
> dispose = BUF_DIRTY;
> + if (buffer_protected(bh))
> + dispose = BUF_PROTECTED;
> if (dispose != bh->b_list) {
> __remove_from_lru_list(bh, bh->b_list);
> bh->b_list = dispose;
> @@ -2071,7 +2074,7 @@
> int found = 0, locked = 0, dirty = 0, used = 0, lastused = 0;
> int protected = 0;
> int nlist;
> - static char *buf_types[NR_LIST] = { "CLEAN", "LOCKED", "DIRTY" };
> + static char *buf_types[NR_LIST] = { "CLEAN", "LOCKED", "DIRTY", "PROTECTED", };
> #endif
>
> printk("Buffer memory: %6dkB\n",
> --- 2.3.35pre4-ramdisk-oom/include/linux/fs.h.~1~ Fri Dec 24 02:20:17 1999
> +++ 2.3.35pre4-ramdisk-oom/include/linux/fs.h Mon Dec 27 00:19:11 1999
> @@ -788,7 +788,8 @@
> #define BUF_CLEAN 0
> #define BUF_LOCKED 1 /* Buffers scheduled for write */
> #define BUF_DIRTY 2 /* Dirty buffers, not yet scheduled for write */
> -#define NR_LIST 3
> +#define BUF_PROTECTED 3 /* Ramdisk persistent storage */
> +#define NR_LIST 4
>
> /*
> * This is called by bh->b_end_io() handlers when I/O has completed.
>
>
> Andrea
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/