search for: daney

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you did with >

On Tue, Jan 12, 2016 at 10:27:11AM +0100, Peter Zijlstra wrote: > 2) the changelog _completely_ fails to explain the sync 0x11 and sync > 0x12 semantics nor does it provide a publicly accessible link to > documentation that does. Ralf pointed me at: https://imgtec.com/mips/architectures/mips64/ > 3) it really should have explained what you did with >

Btrfs uses an rwsem to control access to its extent tree. Threads will hold a read lock on this rwsem while they scan the extent tree, and if need_resched() they will drop the lock and schedule. The transaction commit needs to take a write lock for this rwsem for a very short period to switch out the commit roots. If there are a lot of threads doing this caching operation we can starve out the

...IPS speak, those SYNC types are Ordering Barriers, not > Completion Barriers. They need not be globally performed. Which if true; and I know Will has some questions here; would also mean that you 'cannot' use the ACQUIRE/RELEASE barriers for your locks as was recently suggested by David Daney. That is, currently all architectures -- with exception of PPC -- have RCsc locks, but using these non-transitive things will get you RCpc locks. So yes, MIPS can go RCpc for its locks and share the burden of pain with PPC, but that needs to be a very concious decision.

...es are Ordering Barriers, not > > Completion Barriers. They need not be globally performed. > > Which if true; and I know Will has some questions here; would also mean > that you 'cannot' use the ACQUIRE/RELEASE barriers for your locks as was > recently suggested by David Daney. The issue I have with the SYNC description in the text above is that it describes the single CPU (program order) and the dual-CPU (confusingly named global order) cases, but then doesn't generalise any further. That means we can't sensibly reason about transitivity properties when a third...

...es are Ordering Barriers, not > > Completion Barriers. They need not be globally performed. > > Which if true; and I know Will has some questions here; would also mean > that you 'cannot' use the ACQUIRE/RELEASE barriers for your locks as was > recently suggested by David Daney. The issue I have with the SYNC description in the text above is that it describes the single CPU (program order) and the dual-CPU (confusingly named global order) cases, but then doesn't generalise any further. That means we can't sensibly reason about transitivity properties when a third...

For future rework of try_to_wake_up() we'd like to push part of that onto the CPU the task is actually going to run on, in order to do so we need a generic callback from the existing scheduler IPI. This patch introduces such a generic callback: scheduler_ipi() and implements it as a NOP. I visited existing smp_send_reschedule() implementations and tried to add a call to scheduler_ipi() in

For future rework of try_to_wake_up() we'd like to push part of that onto the CPU the task is actually going to run on, in order to do so we need a generic callback from the existing scheduler IPI. This patch introduces such a generic callback: scheduler_ipi() and implements it as a NOP. I visited existing smp_send_reschedule() implementations and tried to add a call to scheduler_ipi() in

For future rework of try_to_wake_up() we'd like to push part of that onto the CPU the task is actually going to run on, in order to do so we need a generic callback from the existing scheduler IPI. This patch introduces such a generic callback: scheduler_ipi() and implements it as a NOP. I visited existing smp_send_reschedule() implementations and tried to add a call to scheduler_ipi() in

...<danders.dev@gmail.com> David Anders <x0132446@ti.com> David Brown <davidb@codeaurora.org> David Chang <dchang@suse.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Flater <dave@flaterco.com>...

...<danders.dev@gmail.com> David Anders <x0132446@ti.com> David Brown <davidb@codeaurora.org> David Chang <dchang@suse.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Flater <dave@flaterco.com>...

...<danders.dev@gmail.com> David Anders <x0132446@ti.com> David Brown <davidb@codeaurora.org> David Chang <dchang@suse.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Flater <dave@flaterco.com>...

...lt;x0132446@ti.com> David Brown <davidb@codeaurora.org> David Chang <dchang@suse.com> David Chen <david.chen@canonical.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Engraf <david.engraf@sysgo.com&...

...lt;x0132446@ti.com> David Brown <davidb@codeaurora.org> David Chang <dchang@suse.com> David Chen <david.chen@canonical.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Engraf <david.engraf@sysgo.com&...

...codeaurora.org> David Bulkow <David.Bulkow@stratus.com> David Chang <dchang@suse.com> David Chen <david.chen@canonical.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Engraf <david.engraf@sysgo.com&...

...codeaurora.org> David Bulkow <David.Bulkow@stratus.com> David Chang <dchang@suse.com> David Chen <david.chen@canonical.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Engraf <david.engraf@sysgo.com&...

...codeaurora.org> David Bulkow <David.Bulkow@stratus.com> David Chang <dchang@suse.com> David Chen <david.chen@canonical.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Disseldorp <ddiss@suse.de>...

...codeaurora.org> David Bulkow <David.Bulkow@stratus.com> David Chang <dchang@suse.com> David Chen <david.chen@canonical.com> David Cohen <david.a.cohen@intel.com> David Dajun Chen <david.chen@diasemi.com> David Dajun Chen <dchen@diasemi.com> David Daney <ddaney@caviumnetworks.com> David Daney <david.daney@cavium.com> David Daney <ddaney@caviumnetworks.com> David Decotigny <decot@googlers.com> David Dillow <dave@thedillows.org> David Dillow <dillowda@ornl.gov> David Disseldorp <ddiss@suse.de>...

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the

Changes since v1: - replaced my asm-generic patch with an equivalent patch already in tip - add wrappers with virt_ prefix for better code annotation, as suggested by David Miller - dropped XXX in patch names as this makes vger choke, Cc all relevant mailing lists on all patches (not personal email, as the list becomes too long then) I parked this in vhost tree for now, but the