On Wed, Jul 31, 2024 at 12:14:16PM -0600, Shuah Khan wrote:
> On 7/31/24 07:42, Muhammad Usama Anjum wrote:
> > Kind reminder
> >
> > On 7/2/24 3:17 PM, Muhammad Usama Anjum wrote:
> > > Kind reminder
>
> Top post ???
>
> > >
> > > On 6/10/24 10:28 AM, Muhammad Usama Anjum wrote:
> > > > There
On Thu, Apr 18, 2024 at 11:35:11AM +0200, Peter Zijlstra wrote:
> On Wed, Apr 17, 2024 at 03:03:05PM -0500, Elizabeth Figura wrote:
>
> > Ach. I wrote this with the idea that the race isn't meaningful, but
> > looking at it again you're right—there is a harmful race here
On Tue, Apr 16, 2024 at 05:18:56PM -0500, Elizabeth Figura wrote:
> On Tuesday, 16 April 2024 16:18:24 CDT Elizabeth Figura wrote:
> > On Tuesday, 16 April 2024 03:14:21 CDT Peter Zijlstra wrote:
> > > I don't support GE has it in his builds? Last time I tried, building
&g
On Wed, Apr 17, 2024 at 03:03:05PM -0500, Elizabeth Figura wrote:
> Ach. I wrote this with the idea that the race isn't meaningful, but
> looking at it again you're right—there is a harmful race here.
>
> I think it should be fixable by moving the atomic_read inside the lock,
> though.
Right,
On Mon, Apr 15, 2024 at 08:08:12PM -0500, Elizabeth Figura wrote:
> + if (atomic_read(>all_hint) > 0) {
> + spin_lock(>wait_all_lock);
> + spin_lock_nest_lock(>lock, >wait_all_lock);
>
> + prev_count = sem->u.sem.count;
> + ret =
On Wed, Apr 17, 2024 at 01:05:47AM -0500, Elizabeth Figura wrote:
> Here's a (slightly ad-hoc) simplification of the patch into text form inlined
> into this message; hopefully it's readable enough.
Thanks!
Still needed:
s/\`\`/"/g
s/\.\.\ //g
But then it's readable
>
>
On Tue, Apr 16, 2024 at 04:18:24PM -0500, Elizabeth Figura wrote:
> Is the concern about poor performance when ntsync is in use, or is nesting a
> lot of spinlocks like that something that could cause problems for unrelated
> tasks? I'm not familiar enough with the scheduler to know if this can
On Tue, Apr 16, 2024 at 04:18:19PM -0500, Elizabeth Figura wrote:
> Let me know if that's good enough or if I should try to render it into plain
> text somehow.
Plain text is much preferred. I'm more of a text editor kinda guy --
being a programmer and all that.
>
>
On Tue, Apr 16, 2024 at 04:18:17PM -0500, Elizabeth Figura wrote:
> Over different lists. I don't know if there's a better way to name things to
> make that clearer.
D'oh, reading hard. I'll stare more.
On Tue, Apr 16, 2024 at 05:53:45PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 16, 2024 at 05:50:14PM +0200, Peter Zijlstra wrote:
> > On Tue, Apr 16, 2024 at 10:14:21AM +0200, Peter Zijlstra wrote:
> >
> > > > Some aspects of the implementation may
On Mon, Apr 15, 2024 at 08:08:10PM -0500, Elizabeth Figura wrote:
> The intended semantics of the patches are broadly intended to match those of
> the
> corresponding Windows functions. For those not already familiar with the
> Windows
> functions (or their undocumented behaviour), patch 27/27
On Tue, Apr 16, 2024 at 05:50:14PM +0200, Peter Zijlstra wrote:
> On Tue, Apr 16, 2024 at 10:14:21AM +0200, Peter Zijlstra wrote:
>
> > > Some aspects of the implementation may deserve particular comment:
> > >
> > > * In the interest of performance, each ob
On Tue, Apr 16, 2024 at 10:14:21AM +0200, Peter Zijlstra wrote:
> > Some aspects of the implementation may deserve particular comment:
> >
> > * In the interest of performance, each object is governed only by a single
> > spinlock. However, NTSYNC_IOC_WAIT_ALL
On Mon, Apr 15, 2024 at 08:08:10PM -0500, Elizabeth Figura wrote:
> This patch series implements a new char misc driver, /dev/ntsync, which is
> used
> to implement Windows NT synchronization primitives.
This patch series does not apply to anything I have at hand. Nor does it
state anything
On Fri, Dec 08, 2023 at 12:29:37PM -0800, John Hubbard wrote:
> I don't have a strong opinion about how this should be done, and in
> fact I believed at the time that I was bringing the system into
> compliance with what everyone wanted here. :)
>
> There seem to be two conflicting visions:
>
>
On Fri, Nov 03, 2023 at 01:22:54PM +0100, David Hildenbrand wrote:
> On 03.11.23 13:16, Peter Zijlstra wrote:
> > On Tue, Jun 06, 2023 at 12:16:37AM -0700, John Hubbard wrote:
> > > As per a discussion with Muhammad Usama Anjum [1], the following is how
> > > one is
On Fri, Nov 24, 2023 at 09:51:53PM -0500, Guo Ren wrote:
> On Fri, Nov 24, 2023 at 11:15:19AM +0100, Peter Zijlstra wrote:
> > On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> > > From: Christoph Müllner
> > >
> > > The upcoming RISC-V S
On Fri, Nov 24, 2023 at 12:04:09PM +0100, Jonas Oberhauser wrote:
> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).
>
>
> Although those instructions have a bit
On Fri, Nov 24, 2023 at 11:53:06AM +0100, Christoph Müllner wrote:
> > I think ARM64 approached this problem by adding the
> > load-acquire/store-release instructions and for TSO based code,
> > translate into those (eg. x86 -> arm64 transpilers).
> >
> > IIRC Risc-V actually has such
On Fri, Nov 24, 2023 at 08:21:37AM +0100, Christoph Muellner wrote:
> From: Christoph Müllner
>
> The upcoming RISC-V Ssdtso specification introduces a bit in the senvcfg
> CSR to switch the memory consistency model at run-time from RVWMO to TSO
> (and back). The active consistency model can
On Fri, Nov 03, 2023 at 01:59:28PM +0100, David Hildenbrand wrote:
> Okay. the question is if your workflow can be easily adjusted, or if we can
> improve that header handling as a whole.
So on IRC the following was suggested:
make O=defconfig-build headers ; make O=defconfig-build -C
On Fri, Nov 03, 2023 at 01:22:54PM +0100, David Hildenbrand wrote:
> On 03.11.23 13:16, Peter Zijlstra wrote:
> > On Tue, Jun 06, 2023 at 12:16:37AM -0700, John Hubbard wrote:
> > > As per a discussion with Muhammad Usama Anjum [1], the following is how
> > > one is
On Tue, Jun 06, 2023 at 12:16:37AM -0700, John Hubbard wrote:
> As per a discussion with Muhammad Usama Anjum [1], the following is how
> one is supposed to build selftests:
>
> make headers && make -C tools/testing/selftests/mm
>
> Change the selftest build system's lib.mk to fail out with
On Fri, Oct 20, 2023 at 07:24:03PM +0500, Muhammad Usama Anjum wrote:
> Please remove these. These macros would be picked up from the kernel
> headers automatically.
As per the previous discussions, how does that work if you have O= build
directories?
I find this push to force people to do
On Mon, Oct 16, 2023 at 11:50:34AM -0700, srinivas pandruvada wrote:
I'll respond to the rest tomorrow, it's far too late.
> > > Also, same question as to the amd folks; what serializes those
> > > static
> > > variables?
> >
> > That's a good one.
>
> This function which is checking static
On Mon, Oct 16, 2023 at 01:21:20PM -0600, Shuah Khan wrote:
> On 10/6/23 03:55, Muhammad Usama Anjum wrote:
> > Kselftests are kernel tests and must be build with kernel headers from
> > same source version. The kernel headers are already being included
> > correctly in futex selftest Makefile
On Mon, Oct 16, 2023 at 06:20:53AM +, Meng, Li (Jassmine) wrote:
> > > +static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata) {
> > > + int ret, prio;
> > > + u32 highest_perf;
> > > + static u32 max_highest_perf = 0, min_highest_perf = U32_MAX;
> >
> > What serializes
On Fri, Oct 13, 2023 at 11:31:14AM +0800, Meng Li wrote:
> +#define AMD_PSTATE_PREFCORE_THRESHOLD166
> +#define AMD_PSTATE_MAX_CPPC_PERF 255
> +static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata)
> +{
> + int ret, prio;
> + u32 highest_perf;
> + static u32
On Mon, Oct 09, 2023 at 10:49:28AM +0800, Meng Li wrote:
> +static void amd_pstate_init_prefcore(struct amd_cpudata *cpudata)
> +{
> + int ret;
> + u32 highest_perf;
> + static u32 max_highest_perf = 0, min_highest_perf = U32_MAX;
> +
> + ret =
On Mon, Oct 09, 2023 at 10:49:26AM +0800, Meng Li wrote:
> amd-pstate driver also uses SCHED_MC_PRIO, so decouple the requirement
> of CPU_SUP_INTEL from the dependencies to allow compilation in kernels
> without Intel CPU support.
>
> Reviewed-by: Mario Limonciello
> Reviewed-by: Huang Rui
>
30 matches
Mail list logo
