Re: removing the global lock from sys_brk()

Alexander Viro (viro@math.psu.edu)
Fri, 4 Jun 1999 01:49:44 -0400 (EDT)


On Thu, 3 Jun 1999, Linus Torvalds wrote:

>
>
> On Thu, 3 Jun 1999, Chuck Lever wrote:
> >
> > is this more like what you had in mind?
>
> [ deleted ]
>
> Yes, this looks a lot more like what I had in mind. I'll read it through
> once more, but this is basically how I envisioned it. The only thing that
> looks suspect is that I don't think we should need the kernel lock even
> around the merge_segments() call in do_brk():

Linus, what do you think of the following trick:

void fput(struct file *file)
{
if (!atomic_dec_and_test(&file->f_count))
return;
/* we are the sole owners */
atomic_inc(&file->f_count); /* to be compatible with the old
* variant
*/
[yodda, yodda]
}
void lazy_fput(struct file *file)
{
if (!atomic_dec_and_test(&file->f_count))
return;
remove_filp(file);
file->f_next = current->goners;
current->goners = file;
}
void reap_files(void)
{
struct file *list = NULL;
xchg(&list, &current->goners);
if (!list)
return;
lock_kernel();
/* for all elements of the list call locks_remove_flock(),
* __fput() and putting the thing on free list
*/
unlock_kernel();
}

in entry.S upon the return to ring 3 call reap_files(); the part before
lock_kernel() is the natural candidate for inlining, indeed.

use lazy_fput() instead of fput() in places where we know that we will
return to ring 3 soon enough.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/