mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Daniel Wagner <wagi@monom.org>
Cc: serge.hallyn@canonical.com, ebiederm@xmission.com,
	nhorman@tuxdriver.com, tgraf@suug.ch, davem@davemloft.net,
	lizefan@huawei.com, cgroups@vger.kernel.org,
	containers@lists.linux-foundation.org,
	linux-kernel@vger.kernel.org, netdev@vger.kernel.org
Subject: Re: [PATCH 4/7] netprio_cgroup: reimplement priomap expansion
Date: Tue, 20 Nov 2012 06:38:32 -0800	[thread overview]
Message-ID: <20121120143832.GO15971@htj.dyndns.org> (raw)
In-Reply-To: <50AB435E.8060901@monom.org>

Hello, Daniel.

On Tue, Nov 20, 2012 at 09:46:22AM +0100, Daniel Wagner wrote:
> struct netprio_map {
> 	struct rcu_head rcu;
> 	struct netprio_aux *aux;	/* auxiliary config array */
> 	u32 priomap_len;
> 	u32 priomap[];
> };
> 
> Is there a specific reason why aux and priomap is handled
> differently? Couldn't you just use same approach for both variables,
> e.g. re/allocating only them here and leave the allocation struct
> netprio_map in cgrp_css_alloc()?

->aux is no longer added, so the consistency issue doesn't exist
anymore.  The reason why they were handled differently before (or
rather why I didn't change priomap[] to be allocated separately) was
that pointer chasing tends to be more expensive than offsetting.  I
don't know how much effect it would have in this case but things
sitting in packet in/out paths can be very hot so didn't wanna disturb
it.

> Also the algorithm to figure out the size of the array might be a
> bit too aggressive in my opinion. So you always start at
> PRIOMAP_MIN_SIZE and then try to double the size until target_idx
> fits. Wouldn't it make sense to start to look for the new size
> beginning at old->priomap_len and then do the power-of-two increase?

The only downside of always starting from PRIOMAP_MIN_SIZE is
iterating several more times in the sizing loop which isn't really
anything to worry about.  The loop is structured that way because I
wanted to keep the size of the whole thing power-of-two.  Due to the
fields before priomap[], if we size priomap_len power-of-two, we'll
always end up with something slightly over power-of-two, which is
usually the worst size to allocate.

Thanks.

-- 
tejun

  reply	other threads:[~2012-11-20 14:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-20  8:30 [PATCHSET REPOST v2 cgroup/for-3.8] netcls/prio_cgroup: update hierarchy support Tejun Heo
2012-11-20  8:30 ` [PATCH 1/7] netcls_cgroup: move config inheritance to ->css_online() and remove .broken_hierarchy marking Tejun Heo
2012-11-20  8:35   ` Daniel Wagner
2012-11-20  8:30 ` [PATCH 2/7] netprio_cgroup: simplify write_priomap() Tejun Heo
2012-11-20  8:37   ` Daniel Wagner
2012-11-20  8:30 ` [PATCH 3/7] netprio_cgroup: shorten variable names in extend_netdev_table() Tejun Heo
2012-11-20  8:37   ` Daniel Wagner
2012-11-20  8:30 ` [PATCH 4/7] netprio_cgroup: reimplement priomap expansion Tejun Heo
2012-11-20  8:46   ` Daniel Wagner
2012-11-20 14:38     ` Tejun Heo [this message]
2012-11-20 15:09       ` Daniel Wagner
2012-11-20 15:13         ` Tejun Heo
2012-11-20 15:16           ` Daniel Wagner
2012-11-20  8:30 ` [PATCH 5/7] netprio_cgroup: use cgroup->id instead of cgroup_netprio_state->prioidx Tejun Heo
2012-11-20  8:47   ` Daniel Wagner
2012-11-20  8:30 ` [PATCH 6/7] netprio_cgroup: implement netprio[_set]_prio() helpers Tejun Heo
2012-11-20  8:52   ` Daniel Wagner
2012-11-20  8:30 ` [PATCH 7/7] netprio_cgroup: allow nesting and inherit config on cgroup creation Tejun Heo
2012-11-20  8:57   ` Daniel Wagner
2012-11-20 14:40     ` Tejun Heo
2012-11-20 15:10       ` Daniel Wagner
2012-11-20 18:37 ` [PATCHSET REPOST v2 cgroup/for-3.8] netcls/prio_cgroup: update hierarchy support David Miller
2012-11-22 15:33 ` Tejun Heo
  -- strict thread matches above, loose matches on Subject: below --
2012-11-20  7:06 [PATCHSET " Tejun Heo
2012-11-20  7:06 ` [PATCH 4/7] netprio_cgroup: reimplement priomap expansion Tejun Heo

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=20121120143832.GO15971@htj.dyndns.org \
    --to=tj@kernel.org \
    --cc=cgroups@vger.kernel.org \
    --cc=containers@lists.linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=ebiederm@xmission.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=serge.hallyn@canonical.com \
    --cc=tgraf@suug.ch \
    --cc=wagi@monom.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®