On Wed, 2015-04-22 at 15:31 +0200, Mateusz Guzik wrote:
> On Tue, Apr 21, 2015 at 02:06:53PM -0700, Eric Dumazet wrote:
> > On Tue, 2015-04-21 at 22:12 +0200, Mateusz Guzik wrote:
> >
> > > in dup_fd:
> > >for (i = open_files; i != 0; i--) {
> > > struct file *f = *old_fds+
On Tue, Apr 21, 2015 at 02:06:53PM -0700, Eric Dumazet wrote:
> On Tue, 2015-04-21 at 22:12 +0200, Mateusz Guzik wrote:
>
> > in dup_fd:
> >for (i = open_files; i != 0; i--) {
> > struct file *f = *old_fds++;
> > if (f) {
> > get_file
On Tue, 2015-04-21 at 22:12 +0200, Mateusz Guzik wrote:
> in dup_fd:
>for (i = open_files; i != 0; i--) {
> struct file *f = *old_fds++;
> if (f) {
> get_file(f);
>
I see no new requirement here. f is either NULL or not.
multi threa
On Tue, 2015-04-21 at 22:06 +0200, Mateusz Guzik wrote:
> On Tue, Apr 21, 2015 at 11:05:43AM -0700, Eric Dumazet wrote:
> > 3) I avoid multiple threads doing a resize and then only one wins the
> > deal.
> >
>
> One could argue this last bit could be committed separately (a different
> logical c
On Tue, Apr 21, 2015 at 10:06:24PM +0200, Mateusz Guzik wrote:
> On Tue, Apr 21, 2015 at 11:05:43AM -0700, Eric Dumazet wrote:
> > On Mon, 2015-04-20 at 13:49 -0700, Eric Dumazet wrote:
> > > On Mon, 2015-04-20 at 10:15 -0700, Eric Dumazet wrote:
> > > > On Mon, 2015-04-20 at 17:10 +0200, Mateusz G
On Tue, Apr 21, 2015 at 11:05:43AM -0700, Eric Dumazet wrote:
> On Mon, 2015-04-20 at 13:49 -0700, Eric Dumazet wrote:
> > On Mon, 2015-04-20 at 10:15 -0700, Eric Dumazet wrote:
> > > On Mon, 2015-04-20 at 17:10 +0200, Mateusz Guzik wrote:
> > >
> > > > Sorry for spam but I came up with another ha
On Mon, 2015-04-20 at 13:49 -0700, Eric Dumazet wrote:
> On Mon, 2015-04-20 at 10:15 -0700, Eric Dumazet wrote:
> > On Mon, 2015-04-20 at 17:10 +0200, Mateusz Guzik wrote:
> >
> > > Sorry for spam but I came up with another hack. :)
> > >
> > > The idea is that we can have a variable which would
On Mon, 2015-04-20 at 10:15 -0700, Eric Dumazet wrote:
> On Mon, 2015-04-20 at 17:10 +0200, Mateusz Guzik wrote:
>
> > Sorry for spam but I came up with another hack. :)
> >
> > The idea is that we can have a variable which would signify the that
> > given thread is playing with fd table in fd_in
On Mon, 2015-04-20 at 17:10 +0200, Mateusz Guzik wrote:
> Sorry for spam but I came up with another hack. :)
>
> The idea is that we can have a variable which would signify the that
> given thread is playing with fd table in fd_install (kind of a lock
> embedded into task_struct). We would also h
On Mon, 2015-04-20 at 09:46 -0700, Eric Dumazet wrote:
>
> Hey, that's because I really meant (during the week end)
old = xchg(&fdt->fd[fd], file);
if (unlikely(old && old != file))
filp_close(old, files);
That's going to be hard.
If you thought this problem was trivial, it probably me
On Mon, 2015-04-20 at 15:41 +0200, Mateusz Guzik wrote:
> On Sat, Apr 18, 2015 at 12:41:38PM -0700, Eric Dumazet wrote:
> > On Sat, 2015-04-18 at 00:02 +0100, Al Viro wrote:
> > > On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> > >
> > > > I would say this makes the use of seq cou
On Mon, Apr 20, 2015 at 03:43:26PM +0200, Mateusz Guzik wrote:
> On Mon, Apr 20, 2015 at 03:06:33PM +0200, Mateusz Guzik wrote:
> > On Sat, Apr 18, 2015 at 12:02:52AM +0100, Al Viro wrote:
> > > On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> > >
> > > > I would say this makes the
On Mon, Apr 20, 2015 at 03:06:33PM +0200, Mateusz Guzik wrote:
> On Sat, Apr 18, 2015 at 12:02:52AM +0100, Al Viro wrote:
> > On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> >
> > > I would say this makes the use of seq counter impossible. Even if we
> > > decided to fall back to
On Sat, Apr 18, 2015 at 12:41:38PM -0700, Eric Dumazet wrote:
> On Sat, 2015-04-18 at 00:02 +0100, Al Viro wrote:
> > On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> >
> > > I would say this makes the use of seq counter impossible. Even if we
> > > decided to fall back to a lock o
On Sat, Apr 18, 2015 at 12:02:52AM +0100, Al Viro wrote:
> On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
>
> > I would say this makes the use of seq counter impossible. Even if we
> > decided to fall back to a lock on retry, we cannot know what to do if
> > the slot is reserved -
On Sat, 2015-04-18 at 00:02 +0100, Al Viro wrote:
> On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
>
> > I would say this makes the use of seq counter impossible. Even if we
> > decided to fall back to a lock on retry, we cannot know what to do if
> > the slot is reserved - it very
On Sat, Apr 18, 2015 at 12:16:48AM +0200, Mateusz Guzik wrote:
> I would say this makes the use of seq counter impossible. Even if we
> decided to fall back to a lock on retry, we cannot know what to do if
> the slot is reserved - it very well could be that something called
> close, and something
On Fri, Apr 17, 2015 at 02:46:56PM -0700, Eric Dumazet wrote:
> On Thu, 2015-04-16 at 14:16 +0200, Mateusz Guzik wrote:
> > Hi,
> >
> > Currently obtaining a new file descriptor results in locking fdtable
> > twice - once in order to reserve a slot and second time to fill it
>
> ...
>
>
> > vo
On Thu, 2015-04-16 at 14:16 +0200, Mateusz Guzik wrote:
> Hi,
>
> Currently obtaining a new file descriptor results in locking fdtable
> twice - once in order to reserve a slot and second time to fill it
...
> void __fd_install(struct files_struct *files, unsigned int fd,
> struc
On Fri, 2015-04-17 at 00:00 +0200, Mateusz Guzik wrote:
> On Thu, Apr 16, 2015 at 01:55:39PM -0700, Eric Dumazet wrote:
> > On Thu, 2015-04-16 at 13:42 -0700, Eric Dumazet wrote:
> > > On Thu, 2015-04-16 at 19:09 +0100, Al Viro wrote:
> > > > On Thu, Apr 16, 2015 at 02:16:31PM +0200, Mateusz Guzik
On Thu, Apr 16, 2015 at 07:09:32PM +0100, Al Viro wrote:
> On Thu, Apr 16, 2015 at 02:16:31PM +0200, Mateusz Guzik wrote:
> > @@ -165,8 +165,10 @@ static int expand_fdtable(struct files_struct *files,
> > int nr)
> > cur_fdt = files_fdtable(files);
> > if (nr >= cur_fdt->max_fds) {
> >
On Thu, Apr 16, 2015 at 01:55:39PM -0700, Eric Dumazet wrote:
> On Thu, 2015-04-16 at 13:42 -0700, Eric Dumazet wrote:
> > On Thu, 2015-04-16 at 19:09 +0100, Al Viro wrote:
> > > On Thu, Apr 16, 2015 at 02:16:31PM +0200, Mateusz Guzik wrote:
> > > > @@ -165,8 +165,10 @@ static int expand_fdtable(st
On Thu, 2015-04-16 at 13:42 -0700, Eric Dumazet wrote:
> On Thu, 2015-04-16 at 19:09 +0100, Al Viro wrote:
> > On Thu, Apr 16, 2015 at 02:16:31PM +0200, Mateusz Guzik wrote:
> > > @@ -165,8 +165,10 @@ static int expand_fdtable(struct files_struct
> > > *files, int nr)
> > > cur_fdt = files_fdtab
On Thu, 2015-04-16 at 19:09 +0100, Al Viro wrote:
> On Thu, Apr 16, 2015 at 02:16:31PM +0200, Mateusz Guzik wrote:
> > @@ -165,8 +165,10 @@ static int expand_fdtable(struct files_struct *files,
> > int nr)
> > cur_fdt = files_fdtable(files);
> > if (nr >= cur_fdt->max_fds) {
> >
On Thu, Apr 16, 2015 at 02:16:31PM +0200, Mateusz Guzik wrote:
> @@ -165,8 +165,10 @@ static int expand_fdtable(struct files_struct *files,
> int nr)
> cur_fdt = files_fdtable(files);
> if (nr >= cur_fdt->max_fds) {
> /* Continue as planned */
> + write_seqcou
On Thu, 2015-04-16 at 14:16 +0200, Mateusz Guzik wrote:
> Hi,
>
> Currently obtaining a new file descriptor results in locking fdtable
> twice - once in order to reserve a slot and second time to fill it.
>
> Hack below gets rid of the second lock usage.
>
> It gives me a ~30% speedup (~300k ops
Hi,
Currently obtaining a new file descriptor results in locking fdtable
twice - once in order to reserve a slot and second time to fill it.
Hack below gets rid of the second lock usage.
It gives me a ~30% speedup (~300k ops -> ~400k ops) in a microbenchmark
where 16 threads create a pipe (2 fds
27 matches
Mail list logo
