lkml.org 
[lkml]   [2010]   [Aug]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] lglock: make lg_lock_global() actually lock globally
    Hello,

    On 08/26/2010 11:46 AM, Nick Piggin wrote:
    > Oh, I thought we quiesce / preempt all online cpus before adding
    > another one. That sucks if we don't because then you need a big
    > heavy get_online_cpus when a simple preempt_disable would have
    > worked.
    >
    > Why is that? Don't tell me realtime people want some latency "guarantee"
    > while onlining CPUs? :)

    Probably similar rationale of not doing stop_machine() on module
    unload, I suppose. Onlining something is usually considered hotter
    path than offlining. Performance penalty caused by the difference
    between possible and online cpumask or cpu onlining probably only
    matters for very large machines and on those machines stop-machine is
    very expensive. If there's a pressing need, doing stop_machine for
    onlining too is definitely an option.

    >> So, yeah, given that there's no cpu notifier implemented, the use of
    >> for_each_online_cpu for brlock seems fishy to me. It probably should
    >> use for_each_possible_cpu().
    >
    > It should if that's the case, yes.

    IMHO, in most configurations the difference between possible and
    online cpumasks doesn't matter much (they're the same during normal
    operation), so just using possible cpumask should be fine. It's
    already a pretty heavy path, right?

    Thanks.

    --
    tejun


    \
     
     \ /
      Last update: 2010-08-26 11:59    [W:0.045 / U:1.640 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site