All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rodrigo Castro <rcastro@linux.ime.usp.br>
To: linux-mm@kvack.org
Subject: Re: Problems in compressed cache development
Date: Fri, 23 Jun 2000 14:32:50 -0300	[thread overview]
Message-ID: <20000623143250.A25847@linux.ime.usp.br> (raw)
In-Reply-To: <20000623113239.A685@linux.ime.usp.br>; from Rodrigo Castro on Fri, Jun 23, 2000 at 11:32:17AM -0300

	I used GFP_ATOMIC flag to allocate with get_free_page (and
when I tried kmalloc). 
	Now I tried that with GFP_KERNEL and it worked!  We couldn't
understand why it did work. I am calling my function (compressed_copy)
from try_to_free_pages() that is a function from kswapd kernel
thread. By what we understood (reading some documentation about it),
it could result in a deadlock, because we would be trying to get a
free page and how the number of free pages (nr_free_page) was smaller
than the water mark (something like min_free_pages) and it wouldnt
have a concurrent process to free pages to our allocation. What is
wrong with our reasoning?

[]'s
-- 
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

On Fri, Jun 23, 2000 at 11:32:17AM -0300, Rodrigo Castro wrote:
> 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/

--
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 17:32 UTC|newest]

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

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=20000623143250.A25847@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.