On Wed, 2010-10-20 at 16:38 +0200, Ingo Molnar wrote:
> * Eric Paris <eparis@xxxxxxxxxx> wrote:
>
> > Executive summary of the day's work:
> > Yesterday morning: 944 bytes per inode in core
> > Yesterday night: 24 bytes per inode in core
> > Tonight: 4 bytes per inode in core.
> >
> > That's a x236 time reduction in memory usage. No I didn't even start looking at a
> > freezer. Which could bring that 4 down to 0, but would add a scalability penalty
> > on all inodes when IMA was enabled.
>
> Why not use inode->i_security intelligently? That already exists so that way it's 0
> bytes.
>
> Thanks,
It still wouldn't be 0 bytes since there would be a 1-1 mapping from
inode to i_security structs. It would just be hiding the memory
somewhere else so it's harder to spot. And that's exactly how we got
into this situation, instead of just doing thing in the inode we hid it
away in a radix tree node and ima_iint_cache. In any case it would
require a secondary structure
struct generic_lsm_inode_structure
{
IMA Fields
void *lsm_inode_structure;
}
Which means yet another pointer to the real per LSM inode struct. So it
would actually likely cost memory....
The real reason I don't pursue this route is because of the litany of
different ways this pointer is used in different LSMs (or not used at
all.) And we all know that LSM authors aren't known for seeing the
world the same way as each other. As a maintainer of one of those LSMs
even I'm scared to try pushing that forward....
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
