lkml.org 
[lkml]   [1999]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patches in this message
/
From
SubjectRE: [patch] arca-vm-19 [Re: Results: Zlatko's new vm patch] HM Patch
Date

Hallo Andrea!

>
> > On Thu, 14 Jan 1999, Fred Reimer wrote:
>
> > It would not be possible to implement for 2.2.0, because it's frozen except
>
> On Thu, 14 Jan 1999, Amdrea Agneli wrote:
>
> What Heinz is asking for has nothing to do with stability. I think it's
> trivial to do what he needs without having to reinsert the buffer_max
> limit. I think that arca-vm-20 only need an:
>
> echo 5 2 4 32 128 512 >/proc/sys/vm/pager
>
> or a:
>
> echo 3 2 4 32 128 512 >/proc/sys/vm/pager
>

Tested both but got no better performance.

> to work well for Heinz. Heinz could you confirm that? If understand well
> your problem is a too much heavy swapout even if there's a lot of
> freeable buffer memory?
>

Correct!

That's the cause, why i made a quick hack (not that smart for sure ;*) )
which free's buffer memory again, limits page cache and avoids all that
swapping (see patch below).
If the hack makes sense to you my refill_freelist() code should
go to linux/mm/vmscan.c and buffer_mem.max_percent should come back to
implement a better check in grow_buffers().

Did anybody think about correcting linux/Documentation/sysctl/vm.txt?

> > bugs right? But, would it be possible/desireable to have different
> > algorithms selectable as part of the kernel build process? Are their
>
> Sure it's possible but I think it would raise a big mess. I think it's
> very better to have only one algorithm and have it very well tested from
> everybody.

I agree to Andrea's argument and vote for extension of the admin interface
(buffer_mem.max_percent etc.)

Heinz



--- linux/fs/buffer.c.vm20 Fri Jan 8 00:06:59 1999
+++ linux/fs/buffer.c Fri Jan 15 02:27:42 1999
@@ -690,9 +690,42 @@
static void refill_freelist(int size)
{
if (!grow_buffers(size)) {
- wakeup_bdflush(1);
- current->policy |= SCHED_YIELD;
- schedule();
+ /* HM 14.1.99
+ test hack with necessary code parts from shrink_mmap */
+ static unsigned long clock = 0;
+ struct page * page;
+ unsigned long count = num_physpages;
+
+ page = mem_map + clock;
+ while (count-- != 0) {
+
+ /* This works even in the presence of PageSkip because
+ * the first two entries at the beginning of a hole will
+ * be marked, not just the first.
+ */
+ page++;
+ clock++;
+ if (clock >= max_mapnr) {
+ clock = 0;
+ page = mem_map;
+ }
+ if (PageSkip(page)) {
+ /* next_hash is overloaded for PageSkip */
+ page = page->next_hash;
+ clock = page->map_nr;
+ }
+
+ /* We can't free pages unless there's just one user */
+ if (atomic_read(&page->count) != 1)
+ continue;
+
+ /* Is it a buffer page? */
+ if (page->buffers) {
+ if (!try_to_free_buffers(page))
+ continue;
+ break;
+ }
+ }
}
}

@@ -1402,6 +1435,13 @@
struct buffer_head *bh, *tmp;
struct buffer_head * insert_point;
int isize;
+
+ /* HM 14.1.1998
+ test hack, because somebody stole buffer_mem.max_percent ;*) */
+ if ( ( buffermem >> PAGE_SHIFT) * 100 >
+ ( pager_daemon.buffer_min_percent +
+ ( 100 - pager_daemon.buffer_min_percent) / 2) * num_physpages)
+ return 0;

if ((size & 511) || (size > PAGE_SIZE)) {
printk("VFS: grow_buffers: size = %d\n",size);
--- linux/mm/vmscan.c.vm20 Thu Jan 14 17:29:15 1999
+++ linux/mm/vmscan.c Fri Jan 15 02:23:20 1999
@@ -472,6 +472,9 @@

if (!shrink_mmap(priority, gfp_mask))
grow_swap_cache = 1;
+ /* HM 14.1.99; next 2 lines (don't let it grow if we found a page) */
+ else
+ grow_swap_cache = 0;

switch (grow_swap_cache)
{
--

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Systemmanagement Entwicklungsbereich 2 Deutsche Telekom AG
Entwicklungszentrum Darmstadt
Heinz Mauelshagen Otto-Roehm-Strasse 71c
Postfach 10 05 41
mge@ez-darmstadt.telekom.de 64205 Darmstadt
Germany
+49 6151 886-425
FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

-
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/

\
 
 \ /
  Last update: 2005-03-22 13:49    [W:0.084 / U:0.104 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site