Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1313706

Re: [RFC PATCH 18/19] cpufreq: remove transition_lock

From "Rafael J. Wysocki" <rafael@kernel.org>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 18/19] cpufreq: remove transition_lock
Date 2016-01-21 00:40 +0100
Message-ID <qTaw2-58k-25@gated-at.bofh.it> (permalink)
References (2 earlier) <qSK8y-3LS-17@gated-at.bofh.it> <qSMtJ-5dk-29@gated-at.bofh.it> <qT4qD-1bh-33@gated-at.bofh.it> <qT9gE-4lI-75@gated-at.bofh.it> <qT9zY-4u9-19@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


On Wed, Jan 20, 2016 at 11:38 PM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Wed, Jan 20, 2016 at 11:12:45PM +0100, Rafael J. Wysocki wrote:
>> > I would dangle _everything_ off the one driver pointer, that's much
>> > easier.
>>
>> I'm not sure how much easier it is in practice.
>>
>> Even if everything dangles out of the driver pointer, data structures
>> pointed to by those things need not be allocated all in one go by the
>> same entity.  Some of them are allocated by drivers, some of them by
>> the core, at different times.
>
> Yes, I've noticed, some of that is really bonkers.
>
>> The ordering between those allocations
>> and populating the pointers is what matters, not how all that is laid
>> out in memory.
>
> I'm thinking getting that ordering right is easier/more natural, if its
> all contained in one object. But this could be subjective.

I'm trying to look at this from the perspective of making changes.

It should be possible to change the ordering of how the data
structures are populated and pointers set without changing the
existing memory layout of them, which may allow us to minimize the
amount of changes to cpufreq drivers for old hardware (and therefore
generally difficult to test), for example.

Also, this way each individual change may be more limited in scope and
therefore less error prone IMO.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-19 15:10 +0100
  Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-19 15:50 +0100
    Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-19 16:40 +0100
      Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-19 17:10 +0100
        Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-19 20:20 +0100
          Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-19 20:30 +0100
            Re: [RFC PATCH 18/19] cpufreq: remove transition_lock "Rafael J. Wysocki" <rjw@rjwysocki.net> - 2016-01-19 23:00 +0100
              Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-20 18:10 +0100
                Re: [RFC PATCH 18/19] cpufreq: remove transition_lock "Rafael J. Wysocki" <rafael@kernel.org> - 2016-01-20 23:20 +0100
                Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Peter Zijlstra <peterz@infradead.org> - 2016-01-20 23:40 +0100
                Re: [RFC PATCH 18/19] cpufreq: remove transition_lock "Rafael J. Wysocki" <rafael@kernel.org> - 2016-01-21 00:40 +0100
            Re: [RFC PATCH 18/19] cpufreq: remove transition_lock Juri Lelli <juri.lelli@arm.com> - 2016-01-20 14:00 +0100

csiph-web