[linux-mm-cc] Re: [OLPC-devel] Announce: Compressed cache 'pre-alpha-001' release :)

Zach Brown zab at zabbo.net
Thu Jul 27 12:29:38 EDT 2006


> I need to keep 'struct chunk' as small as possible. This 'test_bit'
> usage is
> just super blind copying of page-flags.h :)
> 
> I think this should do (atomic guarantee not required):

Oh, if you don't need atomicity why not just use a bitfield?

	unsigned short	free:1,
			size:15;

or whatever.  Though I think you'll find that most archs are padding it
out to be at least an int anyway to avoid unaligned accesses of
neighbouring members.

> I couldn't find equivalent error codes with meaning of CC_EEXPAND and
> CC_EUSED
> so defined them here.    s/CC_ENOMEM/ENOMEM

So have it return > 0 for the expand case?

> chunk_head is given to page_cache_get() before we know it's 'struct
> page' or
> 'struct chunk_head' so need to keep name and its position same as for
> struct
> page.

Ugh, I missed that detail.  That sounds very dangerous and I don't think
it will be allowed.  You should find a better way.

> Why the 'struct page' has this '_' for count and mapcount?

Because they're not supposed to be used directly, only by helper functions.

> Yes its temporary and I'm not sure how to handle this failed alloc!
> If it fails, we lose the page since its copy is not stored in swap disk.

The swap path can't return an error at this point?  I'd have to look
into the paths here to offer real help :/.

> Having trouble understanding what it is....Will read more on it.

Think of it as a compiler that only parses the code to emit warnings.

- z


More information about the linux-mm-cc mailing list