On Mon, Sep 11, 2023 at 07:00:46PM +0800, Yajun Deng wrote:
> There is a similar name fully in Kconfig.preempt, but it corresponds to
> PREEMPT_RT. In order to distinguish them, change the name of preempt mode
> from full to low_latency.
>
> Also, define a global array and variable that used to sa
On Fri, Sep 15, 2023 at 02:16:50AM +0100, andrew.coop...@citrix.com wrote:
> Juergen has already done the work to delete one of these two patching
> mechanisms and replace it with the other.
>
> https://lore.kernel.org/lkml/a32e211f-4add-4fb2-9e5a-480ae9b9b...@suse.com/
>
> Unfortunately, it's o
FWIW, good to see progress, still waiting for you guys to agree :-)
On Mon, Jul 01, 2019 at 01:15:44PM -0700, bseg...@google.com wrote:
> - Taking up-to-every rq->lock is bad and expensive and 5ms may be too
> short a delay for this. I haven't tried microbenchmarks on the cost of
> this vs
On Mon, Jul 15, 2019 at 09:29:30AM +0100, Will Deacon wrote:
> On Sat, Jul 13, 2019 at 08:10:26PM +0800, Changbin Du wrote:
> > This patch adds a new trace option 'funcgraph-retval' and is disabled by
> > default. When this option is enabled, fgraph tracer will show the return
> > value of each fun
On Tue, Jul 16, 2019 at 10:08:18PM +0800, Changbin Du wrote:
> On Mon, Jul 15, 2019 at 12:12:31PM +0200, Peter Zijlstra wrote:
> > Alternatively, we can have recordmcount (or objtool) mark all functions
> > with a return value when the build has DEBUG_INFO on. The dwarves know
&
On Tue, Jul 23, 2019 at 01:13:09PM -0400, Phil Auld wrote:
> Hi Dave,
>
> On Tue, Jul 23, 2019 at 11:44:26AM -0500 Dave Chiluk wrote:
> > It has been observed, that highly-threaded, non-cpu-bound applications
> > running under cpu.cfs_quota_us constraints can hit a high percentage of
> > periods t
On Mon, Jul 29, 2019 at 06:33:10PM -0700, Suren Baghdasaryan wrote:
> When a process creates a new trigger by writing into /proc/pressure/*
> files, permissions to write such a file should be used to determine whether
> the process is allowed to do so or not. Current implementation would also
> req
On Tue, Jul 30, 2019 at 10:44:51AM -0700, Suren Baghdasaryan wrote:
> On Tue, Jul 30, 2019 at 1:11 AM Peter Zijlstra wrote:
> >
> > On Mon, Jul 29, 2019 at 06:33:10PM -0700, Suren Baghdasaryan wrote:
> > > When a process creates a new trigger by writing into /pro
On Thu, Aug 01, 2019 at 11:28:30AM -0700, Suren Baghdasaryan wrote:
> > By marking it FIFO-99 you're in effect saying that your stupid
> > statistics gathering is more important than your life. It will preempt
> > the task that's in control of the band-saw emergency break, it will
> > preempt the t
On Tue, Aug 20, 2019 at 09:02:59AM +, Jisheng Zhang wrote:
> In v2, actually, the arm64 version's kprobe_ftrace_handler() is the same
> as x86's, the only difference is comment, e.g
>
> /* Kprobe handler expects regs->ip = ip + 1 as breakpoint hit */
>
> while in arm64
>
> /* Kprobe handler
On Tue, Aug 13, 2019 at 01:52:09PM -0700, Yu-cheng Yu wrote:
> +static inline pte_t pte_move_flags(pte_t pte, pteval_t from, pteval_t to)
> +{
> + if (pte_flags(pte) & from)
> + pte = pte_set_flags(pte_clear_flags(pte, from), to);
> + return pte;
> +}
Aside of the whole condit
On Sun, Aug 25, 2019 at 09:23:22PM +0800, Changbin Du wrote:
> Add generic DWARF constant definitions. We will use it later.
>
> Signed-off-by: Changbin Du
> ---
> include/asm-generic/dwarf.h | 199
> 1 file changed, 199 insertions(+)
> create mode 100644 in
On Sun, Aug 25, 2019 at 09:23:24PM +0800, Changbin Du wrote:
> When CONFIG_FTRACE_FUNC_PROTOTYPE is enabled, thousands of
> ftrace_func_entry instances are created. So create a dedicated
> memcache to enhance performance.
>
> Signed-off-by: Changbin Du
> ---
> kernel/trace/ftrace.c | 17
On Tue, Aug 27, 2019 at 03:37:12PM -0700, Yu-cheng Yu wrote:
> On Fri, 2019-08-23 at 16:02 +0200, Peter Zijlstra wrote:
> > On Tue, Aug 13, 2019 at 01:52:09PM -0700, Yu-cheng Yu wrote:
> >
> > > +static inline pte_t pte_move_flags(pte_t pte, pteval_t from, pteval_t
On Wed, Jul 31, 2019 at 01:25:17PM -0700, Paul E. McKenney wrote:
> Looks like a pretty clear consensus thus far. Any objections to keeping
> these .txt for the time being?
Obviously I'm a huge proponent of abandoning RST and an advocate for
normal .txt files ;-)
On Wed, Oct 16, 2019 at 10:39:52AM +0200, Marco Elver wrote:
> +bool __kcsan_check_watchpoint(const volatile void *ptr, size_t size,
> + bool is_write)
> +{
> + atomic_long_t *watchpoint;
> + long encoded_watchpoint;
> + unsigned long flags;
> + enum kcsan
On Wed, Oct 16, 2019 at 09:34:05PM +0200, Marco Elver wrote:
> On Wed, 16 Oct 2019 at 20:44, Peter Zijlstra wrote:
> > > + /*
> > > + * Disable interrupts & preemptions, to ignore races due to
> > > accesses in
> > &g
On Mon, May 13, 2019 at 10:42:42PM -0700, Brendan Higgins wrote:
> This fixes the following warning seen on GCC 7.3:
> kunit/test-test.o: warning: objtool: kunit_test_unsuccessful_try() falls
> through to next function kunit_test_catch()
>
What is that file and function; no kernel tree near me
On Tue, May 14, 2019 at 01:12:23AM -0700, Brendan Higgins wrote:
> On Tue, May 14, 2019 at 08:56:43AM +0200, Peter Zijlstra wrote:
> > On Mon, May 13, 2019 at 10:42:42PM -0700, Brendan Higgins wrote:
> > > This fixes the following warning seen on GCC 7.3:
> > >
(it always helps to Cc the people who actually wrote the code)
Ben, can you have a look at this?
On Thu, May 23, 2019 at 01:44:47PM -0500, Dave Chiluk wrote:
> It has been observed, that highly-threaded, non-cpu-bound applications
> running under cpu.cfs_quota_us constraints can hit a high perc
On Fri, May 24, 2019 at 03:56:35PM +0800, Tao Xu wrote:
> This patch adds support for UMONITOR, UMWAIT and TPAUSE instructions
> in kvm, and by default dont't expose it to kvm and provide a capability
> to enable it.
I'm thinking this should be conditional on the guest being a 1:1 guest,
and I als
On Tue, May 28, 2019 at 06:32:57PM +0200, Marco Elver wrote:
> This is a pre-requisite for enabling bitops instrumentation. Some bitops
> may safely be used with instrumentation in uaccess regions.
>
> For example, on x86, `test_bit` is used to test a CPU-feature in a
> uaccess region: arch/x86/
On Wed, May 29, 2019 at 11:46:10AM +0200, Marco Elver wrote:
> On Wed, 29 May 2019 at 10:55, Dmitry Vyukov wrote:
> >
> > On Tue, May 28, 2019 at 7:19 PM Peter Zijlstra wrote:
> > >
> > > On Tue, May 28, 2019 at 06:32:57PM +0200, Marco Elver wrote:
> > &
On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> For the default, we decided to err on the conservative side for now,
> since it seems that e.g. x86 operates only on the byte the bit is on.
This is not correct, see for instance set_bit():
static __always_inline void
set_bit(long nr,
On Wed, May 29, 2019 at 12:16:31PM +0200, Marco Elver wrote:
> On Wed, 29 May 2019 at 12:01, Peter Zijlstra wrote:
> >
> > On Wed, May 29, 2019 at 11:20:17AM +0200, Marco Elver wrote:
> > > For the default, we decided to err on the conservative side for now,
> >
On Wed, May 29, 2019 at 11:20:56AM +, David Laight wrote:
> From: Dmitry Vyukov
> > Sent: 29 May 2019 11:57
> > Interesting. Does an address passed to bitops also should be aligned,
> > or alignment is supposed to be handled by bitops themselves?
>
> The bitops are defined on 'long []' and it
On Wed, May 29, 2019 at 01:29:51PM +0200, Dmitry Vyukov wrote:
> Thanks. I've filed https://bugzilla.kernel.org/show_bug.cgi?id=203751
> for checking alignment with all the points and references, so that
> it's not lost.
Thanks!
On Thu, Jun 06, 2019 at 01:06:24PM -0700, Yu-cheng Yu wrote:
> Intel Control-flow Enforcement Technology (CET) introduces the
> following MSRs.
>
> MSR_IA32_U_CET (user-mode CET settings),
> MSR_IA32_PL3_SSP (user-mode shadow stack),
> MSR_IA32_PL0_SSP (kernel-mode shadow stack),
>
On Thu, Jun 06, 2019 at 01:06:34PM -0700, Yu-cheng Yu wrote:
> diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
> index 75d9d68a6de7..ffcc0be7cadc 100644
> --- a/include/asm-generic/pgtable.h
> +++ b/include/asm-generic/pgtable.h
> @@ -1188,4 +1188,12 @@ static inline boo
On Thu, Jun 06, 2019 at 01:06:37PM -0700, Yu-cheng Yu wrote:
> There are a few places that need do_mmap() with mm->mmap_sem held.
> Create an in-line function for that.
>
> Signed-off-by: Yu-cheng Yu
> ---
> include/linux/mm.h | 18 ++
> 1 file changed, 18 insertions(+)
>
> diff
On Fri, Jun 07, 2019 at 09:43:22AM +0200, Peter Zijlstra wrote:
> On Thu, Jun 06, 2019 at 01:06:37PM -0700, Yu-cheng Yu wrote:
> > There are a few places that need do_mmap() with mm->mmap_sem held.
> > Create an in-line function for that.
> >
> > Signed-off-by: Yu-
On Thu, Jun 06, 2019 at 01:06:42PM -0700, Yu-cheng Yu wrote:
> +#ifdef CONFIG_ARCH_USE_GNU_PROPERTY
> +int arch_setup_property(void *ehdr, void *phdr, struct file *f, bool inter)
> +{
> + int r;
> + uint32_t property;
Flip those two lines around.
> +
> + r = get_gnu_property(ehdr, ph
On Thu, Jun 06, 2019 at 01:06:41PM -0700, Yu-cheng Yu wrote:
> An ELF file's .note.gnu.property indicates features the executable file
> can support. For example, the property GNU_PROPERTY_X86_FEATURE_1_AND
> indicates the file supports GNU_PROPERTY_X86_FEATURE_1_IBT and/or
> GNU_PROPERTY_X86_FEAT
On Thu, Jun 06, 2019 at 01:09:19PM -0700, Yu-cheng Yu wrote:
> +static int handle_bitmap(unsigned long arg2)
> +{
> + unsigned long addr, size;
> +
> + if (get_user(addr, (unsigned long __user *)arg2) ||
> + get_user(size, (unsigned long __user *)arg2 + 1))
> + return -
On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
> Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
> that allows execution of legacy, non-IBT compatible library by an
> IBT-enabled application. When set, each bit in the bitmap indicates
> one page of legacy code.
On Fri, Jun 07, 2019 at 09:23:43AM -0700, Yu-cheng Yu wrote:
> On Fri, 2019-06-07 at 10:08 +0200, Peter Zijlstra wrote:
> > On Thu, Jun 06, 2019 at 01:09:15PM -0700, Yu-cheng Yu wrote:
> > > Indirect Branch Tracking (IBT) provides an optional legacy code bitmap
> > &g
check would otherwise be flagged by objtool.
>
> For consistency, kernel/signal.c was changed to mirror this change,
> however, is never instrumented with KASAN (currently unsupported under
> x86 32bit).
Acked-by: Peter Zijlstra (Intel)
Thanks!
>
> Signed-off-by: Marco Elver
On Tue, Jun 18, 2019 at 10:12:50AM +0100, Dave Martin wrote:
> On Mon, Jun 17, 2019 at 02:20:40PM +0200, Thomas Gleixner wrote:
> > On Mon, 17 Jun 2019, Florian Weimer wrote:
> > > * Dave Martin:
> > > > On Tue, Jun 11, 2019 at 12:31:34PM -0700, Yu-cheng Yu wrote:
> > > >> We can probably check PT_
On Tue, Jun 18, 2019 at 02:47:00PM +0200, Florian Weimer wrote:
> * Peter Zijlstra:
>
> > I'm not sure I read Thomas' comment like that. In my reading keeping the
> > PT_NOTE fallback is exactly one of those 'fly workarounds'. By not
> > supporting
On Wed, Jun 19, 2019 at 10:19:22AM -0300, Mauro Carvalho Chehab wrote:
> (c/c list cleaned)
>
> Em Wed, 19 Jun 2019 13:43:56 +0200
> Peter Zijlstra escreveu:
>
> > On Tue, Jun 18, 2019 at 05:53:17PM -0300, Mauro Carvalho Chehab wrote:
> >
> > > ..
On Fri, Apr 21, 2017 at 10:12:53PM +0800, Alex Shi wrote:
> diff --git a/Documentation/locking/rt-mutex-design.txt
> b/Documentation/locking/rt-mutex-design.txt
> index 8666070..11beb55 100644
> --- a/Documentation/locking/rt-mutex-design.txt
> +++ b/Documentation/locking/rt-mutex-design.txt
> @@
On Fri, May 12, 2017 at 06:51:50PM -0300, Mauro Carvalho Chehab wrote:
> > * Return:
> > * * 0 - ready to wait
> > * * 1 - acquired the lock
> > * * <0 - error
> >
> > I'm fine with either though, just curious if this would be an improvement,
> > or if
> > we have an established policy (
On Fri, May 12, 2017 at 03:19:17PM -0700, Darren Hart wrote:
> On Sat, May 13, 2017 at 12:11:09AM +0200, Peter Zijlstra wrote:
> > And I really _really_ hate to see that rest crap spread here. Can't we
> > just delete all that nonsense and go back to 80 column 7bit ASCII ?
&g
On Mon, May 15, 2017 at 06:00:46AM -0300, Mauro Carvalho Chehab wrote:
> > Well, I don't mind the '-' thing before return values too much, but the
> > below chunk is just pure drivel. It makes a perfectly good comment
> > worse.
> >
> > --- a/kernel/locking/mutex.c
> > +++ b/kernel/locking/mutex.
On Mon, May 15, 2017 at 01:29:58PM +0300, Jani Nikula wrote:
> On Mon, 15 May 2017, Peter Zijlstra wrote:
> > The intention is to aid readability. Making comments worse so that some
> > retarded script can generate better html or whatnot is just that,
> > retarded.
> >
On Mon, May 15, 2017 at 02:22:39PM -0300, Mauro Carvalho Chehab wrote:
> Yet, on the other hand, nobody wants lots of warnings/errors
> produced when building the Kernel or the documentation, as it can ride
> important things that would require fixes.
So would that actually generate a warn/error?
On Thu, Jun 01, 2017 at 10:50:42AM -0400, Tejun Heo wrote:
> Hello, Waiman.
>
> A short update. I tried making root special while keeping the
> existing threaded semantics but I didn't really like it because we
> have to couple controller enables/disables with threaded
> enables/disables. I'm no
On Wed, Jul 12, 2017 at 10:14:49AM -0400, Steven Rostedt wrote:
> On Tue, 11 Jul 2017 22:39:24 +0800
> Alex Shi wrote:
>
> > Any comments for this little change? It's passed on 0day testing.
>
> I think the problem was that this was a third patch after two
> documentation patches. Where, people
On Tue, Dec 12, 2017 at 01:10:57PM -0800, Megha Dey wrote:
> On Mon, 2017-11-20 at 12:57 +0100, Peter Zijlstra wrote:
> > On Fri, Nov 17, 2017 at 05:54:05PM -0800, Megha Dey wrote:
> > > + mutex_lock(&bm_counter_mutex);
> > > + for (i = 0; i < BM_MAX_C
On Tue, Dec 12, 2017 at 03:08:00PM -0800, Megha Dey wrote:
> >
> > There's work on the way to allow multiple HW PMUs. You'll either have to
> > wait for that or help in making that happen. What you do not do is
> > silently hack around it.
>
> Could I get a pointer to the code implementing this?
On Wed, Jan 03, 2018 at 03:04:36PM +0530, afzal mohammed wrote:
> Let PDF & HTML's be created out of memory-barriers Text by
> reStructuring.
>
> reStructuring done were,
> 1. Section headers modification, lower header case except start
> 2. Removal of manual index(contents section), since it now
On Thu, Jan 18, 2018 at 10:09:51AM -0500, Prarit Bhargava wrote:
> config ACPI_SPCR_TABLE
> + bool "ACPI Serial Port Console Redirection Support"
> + default y if X86
> + help
> + Enable support for Serial Port Console Redirection (SPCR) Table.
> + This table provides infor
On Mon, Feb 12, 2018 at 08:47:57AM -0500, Prarit Bhargava wrote:
>
>
> On 02/12/2018 08:34 AM, Peter Zijlstra wrote:
> > On Thu, Jan 18, 2018 at 10:09:51AM -0500, Prarit Bhargava wrote:
> >> config ACPI_SPCR_TABLE
> >> + bool "ACPI Serial Port Console Red
On Mon, Feb 12, 2018 at 10:18:06AM -0500, Prarit Bhargava wrote:
> > But when I specify "earlyprintk=serial,ttyS0,115200" this SPCR crud will
> > not interfere?
> >
>
> I tested "earlyprintk=serial,ttyS0,115200" on a system which is known to have
> a
> functional console with "console=ttyS0,1152
dep
> asserts might help spread adoption even wider (mostly regarding
> lockdep_pin_lock stuff, which is pretty new and maybe got unnoticed
> outside of the scheduler?).
Thanks for writing that Juri!
Acked-by: Peter Zijlstra (Intel)
--
To unsubscribe from this list: send the line "u
On Wed, Feb 21, 2018 at 11:38:12PM +, James Hogan wrote:
> So lets call it a day and drop the Meta architecture port from the
> kernel. RIP Meta.
So long, and thanks for all the fish!
Nice cleanup though, most welcome :-)
Acked-by: Peter Zijlstra (Intel)
--
To unsubscribe from thi
On Fri, Mar 09, 2018 at 03:43:34PM -0500, Waiman Long wrote:
> The isolcpus= parameter just reduce the cpus available to the rests of
> the system. The cpuset controller does look at that value and make
> adjustment accordingly, but it has no dependence on exclusive cpu/mem
> features of cpuset.
T
On Fri, Mar 09, 2018 at 06:06:29PM -0500, Waiman Long wrote:
> So you are talking about sched_relax_domain_level and
That one I wouldn't be sad to see the back of.
> sched_load_balance.
This one, that's critical. And this is the perfect time to try and fix
the whole isolcpus issue.
The primary
On Thu, Mar 15, 2018 at 04:58:12AM -0700, Matthew Wilcox wrote:
> On Wed, Mar 14, 2018 at 01:56:31PM -0700, Andrew Morton wrote:
> > My memory is weak and our documentation is awful. What does
> > mutex_lock_killable() actually do and how does it differ from
> > mutex_lock_interruptible()?
>
> Fr
On Tue, Mar 20, 2018 at 07:04:28PM +0800, Dou Liyang wrote:
> + possible_cpus= [s390,x86_64] Use this to set hotpluggable cpus.
> + This option sets possible_cpus bits in cpu_possible_map.
> + Thus keeping the numbers of bits set constant even if
> +
On Tue, Mar 20, 2018 at 07:04:30PM +0800, Dou Liyang wrote:
> case 1: no | no | no | --> min (setup_possible_cpus, nr_cpu_ids,
> setup_max_cpus)
> case 2: no | no | yes| --> min (setup_possible_cpus, nr_cpu_ids)
> case 3: no | yes | no | --> 1
> case 4:
On Wed, Mar 21, 2018 at 01:33:24PM +0800, Dou Liyang wrote:
> How about:
>
> possible_cpus=[s390,x86_64] Set the number of possible CPUs which
> are determined by the ACPI tables MADT or mptables by
> default. possible_cpus=n : n >= 1 enforces the possible
>
On Wed, Mar 28, 2018 at 10:57:11AM -0700, Tony Luck wrote:
> On Wed, Mar 28, 2018 at 6:02 AM, Sinan Kaya wrote:
> > +linux-ia64
> > Does IA64 follow this requirement? If not, is implementation planned?
> >
> > "no wmb() before writel()"
> >
> > Linus asked us to get rid of wmb() in front of writel
On Mon, Apr 09, 2018 at 05:51:34PM +0100, Patrick Bellasi wrote:
> The PELT half-life is the time [ms] required by the PELT signal to build
> up a 50% load/utilization, starting from zero. This time is currently
> hardcoded to be 32ms, a value which seems to make sense for most of the
> workloads.
On Mon, Nov 19, 2018 at 08:42:52AM +0300, Alexey Budankov wrote:
>
> Implement initial version of perf-security.rst documentation file
> initially covering security concerns related to PCL/Perf performance
> monitoring in multiuser environments.
Ditch the PCL thing. That's not a term used anywh
On Mon, Nov 19, 2018 at 10:35:59AM +, Jordan Glover wrote:
> On Monday, November 19, 2018 6:42 AM, Alexey Budankov
> wrote:
> > +>=3:
> >
> > - Restrict *access* to PCL performance monitoring for unprivileged
> > processes.
> >
> >
> > - This is the default on Debian and Android
On Mon, Dec 10, 2018 at 12:30:23PM +0100, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki
>
> Add two new metrics for CPU idle states, "above" and "below", to count
> the number of times the given state had been asked for (or entered
> from the kernel's perspective), but the observed idle dura
On Mon, Dec 10, 2018 at 10:36:40PM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 10, 2018 at 1:21 PM Peter Zijlstra wrote:
> > One question on this; why is this tracked unconditionally?
>
> Because I didn't quite see how to make that conditional in a sensible way.
Somethi
On Tue, Dec 11, 2018 at 10:51:48AM +0100, Rafael J. Wysocki wrote:
> On Mon, Dec 10, 2018 at 11:51 PM Peter Zijlstra wrote:
> > Dunno; it could be cold cachelines, at which point it can be fairly
> > expensive. Also, being stuck with API is fairly horrible if you want to
> &g
On Fri, Dec 14, 2018 at 09:15:05AM -0800, Suren Baghdasaryan wrote:
> Eliminate the idle mode and keep the worker doing 2s update intervals
> at all times.
That sounds like a bad deal.. esp. so for battery powered devices like
say Andoird.
In general the push has been to always idle everything, s
On Fri, Dec 14, 2018 at 09:15:06AM -0800, Suren Baghdasaryan wrote:
> The psi monitoring patches will need to determine the same states as
> record_times(). To avoid calculating them twice, maintain a state mask
> that can be consulted cheaply. Do this in a separate patch to keep the
> churn in the
On Fri, Dec 14, 2018 at 09:15:08AM -0800, Suren Baghdasaryan wrote:
> +ssize_t psi_trigger_parse(char *buf, size_t nbytes, enum psi_res res,
> + enum psi_states *state, u32 *threshold_us, u32 *win_sz_us)
> +{
> + bool some;
> + bool threshold_pct;
> + u32 threshold;
> + u32 win_
On Fri, Dec 14, 2018 at 09:15:08AM -0800, Suren Baghdasaryan wrote:
> @@ -358,28 +526,23 @@ static void psi_update_work(struct work_struct *work)
> {
> struct delayed_work *dwork;
> struct psi_group *group;
> + u64 next_update;
>
> dwork = to_delayed_work(work);
> gro
On Mon, Dec 17, 2018 at 05:14:53PM -0800, Suren Baghdasaryan wrote:
> On Mon, Dec 17, 2018 at 7:55 AM Peter Zijlstra wrote:
> > > + if (state_mask & (1 << s))
> >
> > We have the BIT() macro, but I'm honestly not sure that will improve
> >
On Mon, Dec 17, 2018 at 05:21:05PM -0800, Suren Baghdasaryan wrote:
> On Mon, Dec 17, 2018 at 8:22 AM Peter Zijlstra wrote:
> > How well has this thing been fuzzed? Custom string parser, yay!
>
> Honestly, not much. Normal cases and some obvious corner cases. Will
> check
On Tue, Dec 18, 2018 at 11:46:22AM +0100, Peter Zijlstra wrote:
> On Mon, Dec 17, 2018 at 05:21:05PM -0800, Suren Baghdasaryan wrote:
> > On Mon, Dec 17, 2018 at 8:22 AM Peter Zijlstra wrote:
>
> > > How well has this thing been fuzzed? Custom string parser, yay!
> &
On Sun, Jan 06, 2019 at 11:23:07PM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 11:58:23AM +0800, Jason Wang wrote:
> > On 2019/1/3 上午4:57, Michael S. Tsirkin wrote:
> > > +#if defined(COMPILER_HAS_OPTIMIZER_HIDE_VAR) && \
> > > + !defined(ARCH_NEEDS_READ_BARRIER_DEPENDS)
> > > +
> >
On Mon, Jan 07, 2019 at 08:36:36AM -0500, Michael S. Tsirkin wrote:
> On Mon, Jan 07, 2019 at 10:46:10AM +0100, Peter Zijlstra wrote:
> > How about naming the thing: dependent_ptr() ? That is without any (r)mb
> > implications at all. The address dependency is strictly weaker tha
> This also reflects the situation on other architectures, the the port
> accessor macros tend to be implemented in terms of readX/writeX.
>
> Update Documentation/memory-barriers.txt to reflect reality.
>
> Cc: Benjamin Herrenschmidt
> Cc: Arnd Bergmann
> Cc: David Laight
On Thu, Jan 10, 2019 at 02:07:18PM -0800, Suren Baghdasaryan wrote:
> +/*
> + * psi_update_work represents slowpath accounting part while
> + * psi_group_change represents hotpath part.
> + * There are two potential races between these path:
> + * 1. Changes to group->polling when slowpath checks f
On Mon, Jan 14, 2019 at 11:30:12AM -0800, Suren Baghdasaryan wrote:
> For memory ordering (which Johannes also pointed out) the critical point is:
>
> times[cpu] += delta | if g->polling:
> smp_wmb() | g->polling = polling = 0
> cmpxchg(g->polling, 0, 1) | smp
On Wed, Jan 16, 2019 at 02:17:28PM -0500, Johannes Weiner wrote:
> > > Also, you probably want to use atomic_t for g->polling, because we
> > > (sadly) have architectures where regular stores and atomic ops don't
> > > work 'right'.
> >
> > Oh, I see. Will do. Thanks!
>
> Yikes, that's news to m
On Thu, Jan 24, 2019 at 01:15:18PM -0800, Suren Baghdasaryan wrote:
> static void psi_update_work(struct work_struct *work)
> {
> struct delayed_work *dwork;
> struct psi_group *group;
> + bool first_pass = true;
> + u64 next_update;
> + u32 change_mask;
> + int pollin
On Thu, Jan 24, 2019 at 01:15:18PM -0800, Suren Baghdasaryan wrote:
> + atomic_set(&group->polling, polling);
> + /*
> + * Memory barrier is needed to order group->polling
> + * write before times[] read in collect_pe
On Tue, Jan 29, 2019 at 01:38:43PM +0100, Peter Zijlstra wrote:
> On Thu, Jan 24, 2019 at 01:15:18PM -0800, Suren Baghdasaryan wrote:
> > + atomic_set(&group->polling, polling);
> > + /*
> > +* Memory barrier is ne
On Tue, Jan 29, 2019 at 10:18:20AM -0800, Suren Baghdasaryan wrote:
> On Tue, Jan 29, 2019 at 4:38 AM Peter Zijlstra wrote:
> >
> > On Thu, Jan 24, 2019 at 01:15:18PM -0800, Suren Baghdasaryan wrote:
> > > + atomic_set(
On Mon, Feb 18, 2019 at 10:40:05PM -0500, Len Brown wrote:
> From: Len Brown
>
> Some new systems have multiple software-visible die within each package.
> The new CPUID.1F leaf can enumerate this multi-die/package topology.
>
> CPUID.1F a super-set of the CPUID.B "Extended Toplogy Leaf",
> and
On Tue, Feb 19, 2019 at 02:33:59PM -0500, Liang, Kan wrote:
> Besides the generic document, I think we should update x86 document as well,
> which is in Documentation/x86/topology.txt.
>
> The definition of topology_core_cpumask has to be changed to per die, right?
That's what the change to match
On Thu, Feb 21, 2019 at 08:12:25AM -0500, Prarit Bhargava wrote:
> Users cannot disable multiple CPU features with the kernel parameter
> clearcpuid=. For example, "clearcpuid=154 clearcpuid=227" only disables
> CPUID bit 154.
>
> Previous to commit 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as ea
On Thu, Feb 21, 2019 at 08:12:25AM -0500, Prarit Bhargava wrote:
> Users cannot disable multiple CPU features with the kernel parameter
> clearcpuid=. For example, "clearcpuid=154 clearcpuid=227" only disables
> CPUID bit 154.
>
> Previous to commit 0c2a3913d6f5 ("x86/fpu: Parse clearcpuid= as ea
On Wed, Feb 20, 2019 at 10:08:48AM -0500, Len Brown wrote:
> Thanks for the comments, Peter. I'll update the patch to address the
> syntax points. (Maybe checkpatch.pl should be updated to reflect your
> preferences?).
Don't know about checkpatch; I ignore plenty of its output. I think tglx
start
On Thu, Feb 28, 2019 at 10:59:19AM -0500, Len Brown wrote:
> The SDM is like software -- usually (but not always) you are better
> off with the latest version:-)
If only it existed as a .tex file in a git repo. It has been very useful
to have older versions around a number of times.
On Tue, Jul 25, 2017 at 08:17:27AM -0400, Prarit Bhargava wrote:
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 5b1662ec546f..6cd38a25f8ea 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1,8 +1,8 @@
> menu "printk and dmesg options"
>
> config PRINTK_TIME
> -
On Mon, Aug 07, 2017 at 09:52:10AM -0700, John Stultz wrote:
> On Mon, Aug 7, 2017 at 8:52 AM, Prarit Bhargava wrote:
> > +u64 ktime_get_real_log_ts(u64 *offset_real)
> > +{
> > + *offset_real = ktime_to_ns(tk_core.timekeeper.offs_real);
> > +
> > + if (timekeeping_active)
> > +
On Mon, Aug 07, 2017 at 11:52:42AM -0400, Prarit Bhargava wrote:
> +static u64 printk_get_ts(void)
> +{
> + u64 mono, offset_real;
> +
> + if (printk_time <= PRINTK_TIME_LOCAL)
> + return local_clock();
> +
> + if (printk_time == PRINTK_TIME_BOOT)
> + return ktim
On Mon, Aug 07, 2017 at 01:36:39PM -0700, Paul E. McKenney wrote:
> On Mon, Aug 07, 2017 at 04:06:09PM -0400, Prarit Bhargava wrote:
> > peterz? Want to offer a suggestion? The issue is that I'm changing a bool
> > config option to an int and that impacts all the arch's defconfigs. John
> > po
On Tue, Aug 29, 2017 at 11:46:37AM +, Yang Zhang wrote:
> Add poll in do_idle. For UP VM, if there are running task, it will not
> goes into idle path, so we only enable poll in SMP VM.
>
> Signed-off-by: Yang Zhang
> Signed-off-by: Quan Xu
Broken SoB chain.
> diff --git a/kernel/sched/idl
On Tue, Aug 29, 2017 at 11:46:41AM +, Yang Zhang wrote:
> In ttwu_do_wakeup, it will update avg_idle when wakeup from idle. Here
> we just reuse this logic to update the poll time. It may be a little
> late to update the poll in ttwu_do_wakeup, but the test result shows no
> obvious performance
On Mon, Sep 04, 2017 at 04:28:36PM +0200, Oscar Salvador wrote:
> This is just a resend of Waiman Long's patch.
> I could not find why it was not merged to upstream, so I thought
> to give it another chance.
> What follows is what Waiman Long wrote.
>
> Xen has an kernel command line argument "xen
On Tue, Sep 05, 2017 at 08:28:10AM +0200, Juergen Gross wrote:
> On 05/09/17 00:21, Davidlohr Bueso wrote:
> > On Mon, 04 Sep 2017, Peter Zijlstra wrote:
> >
> >> For testing its trivial to hack your kernel and I don't feel this is
> >> something an Adm
1 - 100 of 223 matches
Mail list logo
