On Mon, 14 Nov 2016, David Carrillo-Cisneros wrote:
> > Also, "monr" is a horribly 'word'.
>
> What makes it so bad? (honest question) . Some alternatives:
>
> - res_mon, resm, rmon (Resource Monitor)
> - rmnode, rnode, rmon_node (Resource Monitoring node, similar to
> Resource Monitor ID, but t
> Also, "monr" is a horribly 'word'.
What makes it so bad? (honest question) . Some alternatives:
- res_mon, resm, rmon (Resource Monitor)
- rmnode, rnode, rmon_node (Resource Monitoring node, similar to
Resource Monitor ID, but to reflect that it's a node in a
tree/hierarchy)
- rdt_mon, rdtm (s
On Fri, 11 Nov 2016, David Carrillo-Cisneros wrote:
> On Fri, Nov 11, 2016 at 1:41 AM, Thomas Gleixner wrote:
>
> > I still have not figured out why all of this is necessary and unfortunately
> > there is no real coherent epxlanation of the overall design. The cover
> > letter is not really helpf
On Fri, Nov 11, 2016 at 1:41 AM, Thomas Gleixner wrote:
> On Fri, 11 Nov 2016, Peter Zijlstra wrote:
>> Well, its very hard to suggest alternatives, because there simply isn't
>> anything of content here. This patch just adds locks, and the next few
>> patches don't describe much either.
>>
>> Why
On Fri, 11 Nov 2016, Peter Zijlstra wrote:
> Well, its very hard to suggest alternatives, because there simply isn't
> anything of content here. This patch just adds locks, and the next few
> patches don't describe much either.
>
> Why can't this be RCU?
AFAICT from looking at later patches the c
* Peter Zijlstra wrote:
> On Thu, Nov 10, 2016 at 06:22:17PM -0800, David Carrillo-Cisneros wrote:
> > A possible alternative to nested spinlocks is to use a single rw_lock to
> > protect changes to the monr hierarchy.
> >
> > This works because, when manipulating pmonrs, the monr hierarchy (mo
On Thu, Nov 10, 2016 at 06:22:17PM -0800, David Carrillo-Cisneros wrote:
> A possible alternative to nested spinlocks is to use a single rw_lock to
> protect changes to the monr hierarchy.
>
> This works because, when manipulating pmonrs, the monr hierarchy (monr's
> parent and children) is read b
>> To circumvent this problem, statically define CMT_MAX_NR_PKGS number of
>> lock_class_key's.
>
> That's a proper circumvention. Define a random number on your own.
A judiciously chosen number ;) .
>
>> Additional details in code's comments.
>
> This is
>
> - pointless. Either there are commen
On Sat, 29 Oct 2016, David Carrillo-Cisneros wrote:
> Lockdep needs lock_class_key's to be statically initialized and/or use
> nesting, but nesting is currently hard-coded for up to 8 levels and it's
> fragile to depend on lockdep internals.
> To circumvent this problem, statically define CMT_MAX_N
Per-package locks potentially reduce the contention when compared to the
system-wide approach of the previous CQM/CMT driver.
Lockdep needs lock_class_key's to be statically initialized and/or use
nesting, but nesting is currently hard-coded for up to 8 levels and it's
fragile to depend on lockdep
10 matches
Mail list logo
