From: Tejun Heo <tj@kernel.org>
To: Parav Pandit <pandit.parav@gmail.com>
Cc: cgroups@vger.kernel.org, linux-doc@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-rdma@vger.kernel.org,
lizefan@huawei.com, Johannes Weiner <hannes@cmpxchg.org>,
Doug Ledford <dledford@redhat.com>,
Liran Liss <liranl@mellanox.com>,
"Hefty, Sean" <sean.hefty@intel.com>,
Jason Gunthorpe <jgunthorpe@obsidianresearch.com>,
Haggai Eran <haggaie@mellanox.com>,
Jonathan Corbet <corbet@lwn.net>,
james.l.morris@oracle.com, serge@hallyn.com,
Or Gerlitz <ogerlitz@mellanox.com>,
Matan Barak <matanb@mellanox.com>,
akpm@linux-foundation.org, linux-security-module@vger.kernel.org
Subject: Re: [PATCHv10 1/3] rdmacg: Added rdma cgroup controller
Date: Tue, 5 Apr 2016 10:01:07 -0400 [thread overview]
Message-ID: <20160405140107.GB7822@mtj.duckdns.org> (raw)
In-Reply-To: <CAG53R5Xs9nB_g7pDu6G260EY+iu6hi=fs6eV1ggyk=NwO32oRg@mail.gmail.com>
Hello, Parav.
On Mon, Apr 04, 2016 at 07:22:38PM -0700, Parav Pandit wrote:
> > Is it actually customary to have rdma core module updated more
> > frequently separate from the kernel? Out-of-tree modules being
> > updated separately happens quite a bit but this is an in-kernel
> > module, which usually is tightly coupled with the rest of the kernel.
> >
> Yes.
> rdma core module is compiled as kernel module.
> Its often updated for new features, fixes.
> So kernel version can be one but RDMA core module(s) get updated more
> frequently than kernel.
As it is a fairly isolated domain, to certain extent, it could be okay
to let it go. At the same time, I know that these enterprise things
tend to go completely wayward and am worried about individual drivers
going crazy with custom attributes in a non-sensical way. The
interface this patch is proposing easily allows that and that at the
cost of internal engineering flexibility. I don't really want to be
caught up in a situation where we're forced to include broken usages
because that's what's already out in the wild. I personally would
much prefer the resources to be defined rigidly. Let's see how the
discussion with Christoph evolves.
> > I don't remember the details well but the code was vastly more complex
> > back then and the object lifetime management was muddy at best. If I
> > reviewed in a contradicting way, my apologies, but given the current
> > code, it'd be better to have objects creation upfront.
>
> Do you mean,
> try_charge() should
> lock()
> run loop to allocate in hierarchy, if not allocated.
> run loop again to charge.
> unlock()
>
> If so, I prefer to run the loop once.
In the original review message, I mentioned creating an interface
which creates the hierarchy of objects as necessary and returns the
target pool with lock held, can you please give it a shot? Something
like the following.
pool *get_pool(...)
{
lock;
if (target pool exists)
return pool w/ lock held;
create the pool hierarchically (might involve unlock);
if (succeeded)
return pool w/ lock held;
return NULL w/o lock;
}
> > It isn't necessarily about speed. It makes clear that the parent
> > always should exist and makes the code easier to read and update.
>
> It doesn't have to exist. It can get allocated when charging occurs.
> Otherwise even if rdma resources are not used, it ends up allocating
> rpool in hierarchy. (We talked this before)
Sure, create pools only for the used combinations but do that
hierarchically so that a child pool always has a parent. I can
promise you that the code will read a lot better with that.
> > I don't know why you end up missing basic patterns so badly. It's
> > making the review and iteration process pretty painful. Please don't
> > be confrontational and try to read the review comments assuming good
> > will.
> >
> My understanding of seq_printf() being blocking call and accessing
seq_printf() can be called from any context; otherwise, it would be a
horrible interface to use, wouldn't it?
> pool_info in spin lock context, made me allocate memory to get all
> values upfront through allocation.
> Now that the lock is going away, I can do what you have described above.
Thanks.
--
tejun
next prev parent reply other threads:[~2016-04-05 14:01 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-24 20:22 [PATCHv10 0/3] rdmacg: IB/core: rdma controller support Parav Pandit
2016-03-24 20:22 ` [PATCHv10 1/3] rdmacg: Added rdma cgroup controller Parav Pandit
2016-04-04 19:36 ` Tejun Heo
2016-04-04 22:50 ` Parav Pandit
2016-04-05 1:25 ` Tejun Heo
2016-04-05 2:22 ` Parav Pandit
2016-04-05 14:01 ` Tejun Heo [this message]
2016-04-05 14:07 ` Tejun Heo
2016-04-05 14:14 ` Parav Pandit
2016-04-05 14:25 ` Parav Pandit
2016-04-05 14:46 ` Tejun Heo
2016-04-05 9:06 ` Christoph Hellwig
2016-04-05 12:39 ` Parav Pandit
2016-04-05 12:42 ` Christoph Hellwig
2016-04-05 12:55 ` Parav Pandit
2016-04-05 15:44 ` Leon Romanovsky
2016-04-05 17:27 ` Christoph Hellwig
2016-04-19 8:56 ` Parav Pandit
2016-03-24 20:22 ` [PATCHv10 2/3] IB/core: added support to use " Parav Pandit
2016-03-24 20:22 ` [PATCHv10 3/3] rdmacg: Added documentation for rdmacg Parav Pandit
2016-06-03 10:56 [PATCHv10 1/3] rdmacg: Added rdma cgroup controller Parav Pandit
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=20160405140107.GB7822@mtj.duckdns.org \
--to=tj@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=cgroups@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=dledford@redhat.com \
--cc=haggaie@mellanox.com \
--cc=hannes@cmpxchg.org \
--cc=james.l.morris@oracle.com \
--cc=jgunthorpe@obsidianresearch.com \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-rdma@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=liranl@mellanox.com \
--cc=lizefan@huawei.com \
--cc=matanb@mellanox.com \
--cc=ogerlitz@mellanox.com \
--cc=pandit.parav@gmail.com \
--cc=sean.hefty@intel.com \
--cc=serge@hallyn.com \
/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;
as well as URLs for NNTP newsgroup(s).