linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Rodrigo Castro <rcastro@linux.ime.usp.br>
To: linux-mm@kvack.org
Subject: Problems in compressed cache development
Date: Fri, 23 Jun 2000 11:32:39 -0300	[thread overview]
Message-ID: <20000623113239.A685@linux.ime.usp.br> (raw)

Hello,

	I am an undergraduate student at University of Sao Paulo,
Brazil and I am working on a compressed cache implementation for Linux
kernel. Our group (there are two more students plus two professors) is
working on version 2.2.14 and we are just crawling in our
development. We've been spending such a long time studying memory
management system and we've started working on source code for about
two months. We implemented some functions to initialize a slab cache,
this cache is supposed to be the heart of our system, and a function
that copies the first ten pages that goes to swap (yeah, the first 10
that go to disk). We did that by allocating a page using get_free_page
and copying memory data with copy_page macro. Well, everything worked
just fine until we put that to work. Our test machine had 22 Mb of
free memory. We allocated 20 Mb with a test program, and after that,
allocated 3 Mb in order to force swapping pages. What happened is our
second test program (the one that allocated 3 Mb) has been killed by
VM (message from kern.log: VM: killing process test). Well, we
replaced get_free_page by kmalloc and we had the same problem. A
sudden idea came to our mind that we should be updating some variable
related to the free pages number, but we couldn't find which one would
be this (these) variable(s). Well, I am writing to you 'cause I would
like to know if you could have an idea of what may be happening, or
what we could do to find a solution to that. We've been studying the
code, and reading many books, but unsuccesfully. Could you give us a
hand?

PS: We changed and allocated the 10 pages at initialization. Using
that, our test program worked, but it would be really useful to know
why we can't make it working allocating dynamically. 
PPS: After killing our process, if we run it again, trying to allocate
the 3 Mb, it works! Oh, the problem procedure is reproducible.

Thank you in advance,
-- 
Rodrigo Castro   <rcastro@linux.ime.usp.br>
Computer Science undergraduate student - University of Sao Paulo

Show me a sane man and I will cure him for you.
                -- C.G. Jung

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/

             reply	other threads:[~2000-06-23 14:32 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-06-23 14:32 Rodrigo Castro [this message]
2000-06-23 17:32 ` Rodrigo Castro

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20000623113239.A685@linux.ime.usp.br \
    --to=rcastro@linux.ime.usp.br \
    --cc=linux-mm@kvack.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox