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 =
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) {
> >
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(f);
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, 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
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
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
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
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 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 signify the
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 hack. :)
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 change).
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 Guzik
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 threaded
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
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
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(>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 means
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
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
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
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 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_install
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 on retry,
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 a lock on
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 - it very
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 use of seq
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 have
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 counter
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 means
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
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 well
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
>
> ...
>
>
> >
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,
>
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,
struct
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
...
void
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, 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
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 =
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 */
> +
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
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
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
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 -
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, 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_fdtable(files);
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(struct
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 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 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) {
/* Continue as planned */
+
54 matches
Mail list logo
