All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Lucian Adrian Grijincu <lucian.grijincu@gmail.com>
Cc: linux-kernel <linux-kernel@vger.kernel.org>,
	netdev@vger.kernel.org, Octavian Purdila <tavi@cs.pub.ro>,
	"David S . Miller" <davem@davemloft.net>,
	Alexey Dobriyan <adobriyan@gmail.com>,
	Damien Millescamps <damien.millescamps@6wind.com>,
	Anca Emanuel <anca.emanuel@gmail.com>,
	Benjamin LaHaise <bcrl@kvack.org>
Subject: Re: v6: faster tree-based sysctl implementation
Date: Sun, 18 Dec 2011 00:05:31 -0800	[thread overview]
Message-ID: <m1fwgipano.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <m1obv9rkyp.fsf@fess.ebiederm.org> (Eric W. Biederman's message of "Fri, 16 Dec 2011 00:15:26 -0800")


I spent some time playing this and managed to get something that works
using proc_dir_entries.  And while it is simpler (600 less lines of
code) it takes about 3x the space of just what using ctl_table entries
does.

I managed to prove to myself that the current sysctl infrastructure
relies the union directory existence semantics pretty strongly.  Despite
all of Al's work to the contrary when he introduced attached_by and kin
in sysctl head.

One nice thing I managed to do was to shift around the problem a bit
so that only at /proc/sys/net do we to namespace weirdness.  Which also
considerably simplifies the problem.

Now that I know that normal unix directory semantics are a lost cause
removing the child entry from ctl_table looks like a very productive
exercise.  

Furthermore it feels like the optimal data structure would be a
directory tree that is created on demand as we create entries,
and a second copy of that directory tree that is per network namespace.

That is very similar to the data structure you wound up with.

So in the next little bit I am going to see if I can combine what
you did and what I did and see if I can come up with something that
is obvious in how it works from looking at it's data structures.

Eric

      reply	other threads:[~2011-12-18  8:04 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-05  7:55 v6: faster tree-based sysctl implementation Lucian Adrian Grijincu
2011-12-06 14:11 ` Anca Emanuel
2011-12-06 14:33   ` Lucian Adrian Grijincu
2011-12-06 16:47     ` Damien Millescamps
2011-12-06 18:42       ` Benjamin LaHaise
2011-12-06 23:42     ` Anca Emanuel
2011-12-07  0:08       ` Anca Emanuel
2011-12-07  1:44         ` Lucian Adrian Grijincu
2011-12-08  0:19           ` Eric W. Biederman
2011-12-16  8:15 ` Eric W. Biederman
2011-12-18  8:05   ` Eric W. Biederman [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m1fwgipano.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=adobriyan@gmail.com \
    --cc=anca.emanuel@gmail.com \
    --cc=bcrl@kvack.org \
    --cc=damien.millescamps@6wind.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lucian.grijincu@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=tavi@cs.pub.ro \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.