[RFC] do_execve() perf improvement opportunity?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



do_execve() on EVERY entry/exit allocates and frees a structure pointed to
by the 'bprm' variable.

I'm thinking it may be possible to very cheaply cache a pointer to the last
allocation here rather than freeing it and just recycle it for the next exec
saving a trip through the slab machanism.

On x86 I'm pretty sure this could be done very racy and lockless (other than
XCHG's implied locks).  Other architectures that don't have an implied
locking instruction might need a hard lock of some sort.

Something along the lines of (pseudocode):

static volatile struct blahblah *p = NULL;

/* ...before the exec... */
bprm = NULL
xchg(bprm, p)
if (bprm == NULL) kmalloc like it is now

/*
  blah, blah, blah...exec triage blob as it exists today
*/

/* ...after the exec...*/
xchg(bprm, p) /* cache what we just used */
if (bprm)     /* Maybe free someone else's if it was still available */
    kfree(bprm);

For things that proceed mostly sequentially like a lot of shell scripts,
Linux builds, etc this simple minded high-speed low-drag, single structure
racy implementation might provide a nice gain for minimal cost.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux