From: "Rodrigo S. de Castro" <rodsc@bigfoot.com>
To: Marcelo Tosatti <marcelo@conectiva.com.br>
Cc: linux-mm@kvack.org, kernel@tutu.ime.usp.br
Subject: Re: [RFC] Structure in Compressed Cache
Date: Wed, 1 Nov 2000 18:51:50 -0200 [thread overview]
Message-ID: <20001101185150.A967@einstein> (raw)
In-Reply-To: <Pine.LNX.4.21.0010311404210.1475-100000@freak.distro.conectiva>; from marcelo@conectiva.com.br on Tue, Oct 31, 2000 at 02:06:08PM -0200
On Tue, Oct 31, 2000 at 02:06:08PM -0200, Marcelo Tosatti wrote:
> On Mon, 30 Oct 2000, Rodrigo S. de Castro wrote:
> > In my implementation of compressed cache (kernel 2.2.16), I
> > started the project having my cache as a slab cache, structure
> > provided by kernel. I have all step 1 (a cache with no compression)
> > done, but I had a problem with marking pages in my cache. After an
> > email sent to the list about this subject, I started looking at shared
> > memory mechanism (mainly ipc/shm.c), and I saw that there's another
> > way of making it: with a page table allocation and memory mapping. I
> > could go on with my initial idea (with slab cache) but I think that
> > doing the latter way (with page table and memory mapping) would be
> > more complete (and, of course, harder). I will have a pool of
> > (compressed) pages that gotta be always in memory and will be
> > "between" physical memory and swap. As the project is growing I would
> > like to define now which path to follow, taking in account
> > completeness and upgradeability (to future versions of kernel). Which
> > way do you think that is better? Please, I also ask you to tell me in
> > case you know if there's another way, maybe better, of doing it.
>
> Slab cache memory is physically contiguous and non swappable, so it may be
> a waste to use it to cache userspace data.
Today I reread Bonwick's paper (The Slab Allocator: An
Object-Caching Kernel Memory Allocator) and I saw that a slab of
objects 'consists of one or more pages of virtually contiguous memory'
and the whole cache (that has many slabs) doesn't, necessarily. I am
storing on a slab cache only a small structure that holds some
information about and a pointer to a physical page that is allocated
in its constructor. In that way, a slab will certainly have a size of
a page (since its structure is smaller than 1/8 of page), and thus
there's no problem for us at all, because there won't have actually
any continguous data. I hope you could get it. I am wondering if I
missing something, because I can't see a problem that this approach
would waste. :-) I did tried to understand some code of slab.c and
even then I couldn't see contiguous memory problem in our whole
cache. Well, I ask anyone who knows something about slab cache to join
this discussion. :-)
[]'s
--
Rodrigo S. de Castro <rcastro@linux.ime.usp.br>
University of Sao Paulo - Brazil
Compressed Caching - http://tutu.ime.usp.br
--
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/
prev parent reply other threads:[~2000-11-01 21:25 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-30 21:09 [RFC] Structure in Compressed Cache Rodrigo S. de Castro
2000-10-31 16:06 ` Marcelo Tosatti
2000-10-31 19:15 ` Rodrigo S. de Castro
2000-11-01 20:51 ` Rodrigo S. de 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=20001101185150.A967@einstein \
--to=rodsc@bigfoot.com \
--cc=kernel@tutu.ime.usp.br \
--cc=linux-mm@kvack.org \
--cc=marcelo@conectiva.com.br \
/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.