On 5/20/2024 10:32 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Flush to guarantee no workers are running when suspend returns.
Add a lock to enforce ordering between clearing running, flushing,
and posting new work in vdpasim_kick_vq. It must be a spin lock
On 5/20/2024 10:30 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Support the suspend operation. There is little to do, except flush to
guarantee no workers are running when suspend returns.
Signed-off-by: Steve Sistare
---
drivers/vdpa/vdpa_user/vduse_dev.c
On 5/20/2024 10:28 PM, Jason Wang wrote:
On Mon, May 20, 2024 at 11:21 PM Steve Sistare
wrote:
Flush to guarantee no workers are running when suspend returns.
Fixes: f345a0143b4d ("vhost-vdpa: uAPI to suspend the device")
Signed-off-by: Steve Sistare
Acked-by: Eugenio Pérez
---
On 2/15/2024 10:44 AM, Eugenio Perez Martin wrote:
> On Wed, Feb 14, 2024 at 8:52 PM Steven Sistare
> wrote:
>>
>> On 2/14/2024 2:39 PM, Eugenio Perez Martin wrote:
>>> On Wed, Feb 14, 2024 at 6:50 PM Steven Sistare
>>> wrote:
>>>>
>&g
On 2/14/2024 2:39 PM, Eugenio Perez Martin wrote:
> On Wed, Feb 14, 2024 at 6:50 PM Steven Sistare
> wrote:
>>
>> On 2/13/2024 11:10 AM, Eugenio Perez Martin wrote:
>>> On Mon, Feb 12, 2024 at 6:16 PM Steve Sistare
>>> wrote:
>>>>
>>>
On 2/13/2024 11:10 AM, Eugenio Perez Martin wrote:
> On Mon, Feb 12, 2024 at 6:16 PM Steve Sistare
> wrote:
>>
>> Flush to guarantee no workers are running when suspend returns.
>>
>> Signed-off-by: Steve Sistare
>> ---
>> drivers/vdpa/vdpa_sim/vdpa_sim.c | 13 +
>> 1 file changed,
On 2/13/2024 10:58 AM, Eugenio Perez Martin wrote:
> On Mon, Feb 12, 2024 at 6:16 PM Steve Sistare
> wrote:
>>
>> Flush to guarantee no workers are running when suspend returns.
>>
>> Signed-off-by: Steve Sistare
>
> Acked-by: Eugenio Pérez
>
> Should this have a Fixes tag?
Sure, I will
Changes in V2:
- test DRIVER_OK instead of FEATURES_OK
- post singly, and add RB and acks
- Steve
On 2/9/2024 5:30 PM, Steve Sistare wrote:
> vdpasim_do_reset sets running to true, which is wrong, as it allows
> vdpasim_kick_vq to post work requests before the device has been
> configured.
On 2/12/2024 12:16 PM, Steve Sistare wrote:
> Flush to guarantee no workers are running when suspend returns,
> for vdpa, vpa_sim, and vduse. (mlx5 already does so, via the path
> mlx5_vdpa_suspend -> unregister_link_notifier -> flush_workqueue.)
Changes in V2:
- renamed "vduse: suspend" (was
On 2/13/2024 9:58 AM, Eugenio Perez Martin wrote:
> On Tue, Feb 13, 2024 at 3:26 PM Steve Sistare
> wrote:
>>
>> If a vdpa device is not in state DRIVER_OK, then there is no driver state
>> to preserve, so no need to call the suspend and resume driver ops.
>>
>> Suggested-by: Eugenio Perez
On 2/12/2024 10:56 AM, Michael S. Tsirkin wrote:
> On Mon, Feb 12, 2024 at 09:56:31AM -0500, Steven Sistare wrote:
>> On 2/12/2024 3:19 AM, Michael S. Tsirkin wrote:
>>> On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote:
>>>> Calling suspend or resume requ
On 2/12/2024 3:19 AM, Michael S. Tsirkin wrote:
> On Fri, Feb 09, 2024 at 02:29:59PM -0800, Steve Sistare wrote:
>> Calling suspend or resume requires VIRTIO_CONFIG_S_DRIVER_OK, for all
>> vdpa devices.
>>
>> Suggested-by: Eugenio Perez Martin "
>> Signed-off-by: Steve Sistare
>
> I don't think
On 1/22/2024 5:59 AM, Stefano Garzarella wrote:
> On Mon, Jan 22, 2024 at 11:47:22AM +0100, Eugenio Perez Martin wrote:
>> On Mon, Jan 22, 2024 at 11:22 AM Stefano Garzarella
>> wrote:
>>>
>>> On Wed, Jan 17, 2024 at 11:23:23AM -0800, Steve Sistare wrote:
>>> >vdpasim_do_reset sets running to
On 1/16/2024 1:14 PM, Eugenio Perez Martin wrote:
> On Wed, Jan 10, 2024 at 9:40 PM Steve Sistare
> wrote:
>>
>> When device ownership is passed to a new process via VHOST_NEW_OWNER,
>> some devices need to know the new userland addresses of the dma mappings.
>> Define the new iotlb message type
On 1/10/2024 5:24 PM, Michael S. Tsirkin wrote:
> On Wed, Jan 10, 2024 at 12:40:03PM -0800, Steve Sistare wrote:
>> Remember the count of pinned memory for the device.
>>
>> Signed-off-by: Steve Sistare
>
> Can we have iommufd support in vdpa so we do not keep extending these hacks?
I assume
On 1/10/2024 9:55 PM, Jason Wang wrote:
> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
> wrote:
>>
>> Live update is a technique wherein an application saves its state, exec's
>> to an updated version of itself, and restores its state. Clients of the
>> application experience a brief
On 1/10/2024 10:08 PM, Jason Wang wrote:
> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
> wrote:
>>
>> When device ownership is passed to a new process via VHOST_NEW_OWNER,
>> some devices need to know the new userland addresses of the dma mappings.
>> Define the new iotlb message type
On 1/10/2024 10:09 PM, Jason Wang wrote:
> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
> wrote:
>>
>> To pass ownership of a live vdpa device to a new process, the user
>> suspends the device, calls VHOST_NEW_OWNER to change the mm, and calls
>> VHOST_IOTLB_REMAP to change the user virtual
On 1/16/2024 1:57 PM, Eugenio Perez Martin wrote:
> On Wed, Jan 10, 2024 at 9:40 PM Steve Sistare
> wrote:
>>
>> To pass ownership of a live vdpa device to a new process, the user
>> suspends the device, calls VHOST_NEW_OWNER to change the mm, and calls
>> VHOST_IOTLB_REMAP to change the user
On 1/11/2024 9:28 PM, Jason Wang wrote:
> On Fri, Jan 12, 2024 at 12:18 AM Mike Christie
> wrote:
>>
>> On 1/10/24 9:09 PM, Jason Wang wrote:
>>> On Thu, Jan 11, 2024 at 4:40 AM Steve Sistare
>>> wrote:
To pass ownership of a live vdpa device to a new process, the user
suspends
Glad to hear it, thanks - Steve
On 12/4/2023 8:35 AM, Michael S. Tsirkin wrote:
> It's in my tee and I'm sending it to Linus.
>
> On Mon, Dec 04, 2023 at 08:33:22AM -0500, Steven Sistare wrote:
>> What's the decision here, pull it, or do not fix it?
>>
>> - Steve
What's the decision here, pull it, or do not fix it?
- Steve
On 11/3/2023 8:26 AM, Steve Sistare wrote:
> mlx5_vdpa does not preserve userland's view of vring base for the control
> queue in the following sequence:
>
> ioctl VHOST_SET_VRING_BASE
> ioctl VHOST_VDPA_SET_STATUS
On 8/3/2020 11:42 AM, James Bottomley wrote:
> On Mon, 2020-08-03 at 10:28 -0500, Eric W. Biederman wrote:
> [...]
>> What is wrong with live migration between one qemu process and
>> another qemu process on the same machine not work for this use case?
>>
>> Just reusing live migration would seem
On 8/3/2020 11:28 AM, ebied...@xmission.com wrote:
> Steven Sistare writes:
>> On 7/30/2020 5:58 PM, ebied...@xmission.com wrote:
>>> Here is another suggestion.
>>>
>>> Have a very simple program that does:
>>>
>>> for (;
On 7/27/2020 1:11 PM, Anthony Yznaga wrote:
> This patchset adds support for preserving an anonymous memory range across
> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
> sharing memory in this manner, as opposed to re-attaching to a named shared
> memory segment, is
On 7/31/2020 1:48 PM, Jason Gunthorpe wrote:
> On Fri, Jul 31, 2020 at 01:15:34PM -0400, Steven Sistare wrote:
>> On 7/31/2020 12:56 PM, Jason Gunthorpe wrote:
>>> On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
>>>>> Your preservation-across-exec
On 7/31/2020 12:56 PM, Jason Gunthorpe wrote:
> On Fri, Jul 31, 2020 at 12:11:52PM -0400, Steven Sistare wrote:
>>> Your preservation-across-exec use-case might or might not need the
>>> VMA to be mapped at the same address.
>>
>> It does. qemu registers
On 7/31/2020 11:27 AM, Matthew Wilcox wrote:
> On Fri, Jul 31, 2020 at 10:57:44AM -0400, Steven Sistare wrote:
>> Matthews sileby/mshare proposal has the same issue. If a process opts-in
>> and mmap's an address in the shared region, then content becomes mapped at
>>
On 7/30/2020 5:58 PM, ebied...@xmission.com wrote:
> Steven Sistare writes:
>> On 7/30/2020 1:49 PM, Matthew Wilcox wrote:
>>> On Thu, Jul 30, 2020 at 01:35:51PM -0400, Steven Sistare wrote:
>>>> mshare + VA reservation is another possible solution.
>>>>
On 7/30/2020 1:49 PM, Matthew Wilcox wrote:
> On Thu, Jul 30, 2020 at 01:35:51PM -0400, Steven Sistare wrote:
>> mshare + VA reservation is another possible solution.
>>
>> Or MADV_DOEXEC alone, which is ready now. I hope we can get back to
>> reviewing that.
>
On 7/30/2020 1:12 PM, Matthew Wilcox wrote:
> On Thu, Jul 30, 2020 at 11:59:42AM -0400, Steven Sistare wrote:
>> On 7/30/2020 11:22 AM, Matthew Wilcox wrote:
>>> On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
>>>> This patchset adds support for preser
On 7/30/2020 11:22 AM, Matthew Wilcox wrote:
> On Mon, Jul 27, 2020 at 10:11:22AM -0700, Anthony Yznaga wrote:
>> This patchset adds support for preserving an anonymous memory range across
>> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
>> sharing memory in this
On 7/28/2020 10:23 AM, Andy Lutomirski wrote:
>> On Jul 27, 2020, at 10:02 AM, Anthony Yznaga
>> wrote:
>>
>> This patchset adds support for preserving an anonymous memory range across
>> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
>> sharing memory in this
On 7/28/2020 9:22 AM, Kirill Tkhai wrote:
> On 27.07.2020 20:11, Anthony Yznaga wrote:
>> madvise MADV_DOEXEC preserves a memory range across exec. Initially
>> only supported for non-executable, non-stack, anonymous memory.
>> MADV_DONTEXEC reverts the effect of a previous MADV_DOXEXEC call and
On 7/27/2020 1:07 PM, ebied...@xmission.com wrote:
> Anthony Yznaga writes:
>
>> This patchset adds support for preserving an anonymous memory range across
>> exec(3) using a new madvise MADV_DOEXEC argument. The primary benefit for
>> sharing memory in this manner, as opposed to re-attaching
On 5/13/2019 7:35 AM, Peter Zijlstra wrote:
> On Mon, May 13, 2019 at 03:04:18PM +0530, Viresh Kumar wrote:
>> On 10-05-19, 09:21, Peter Zijlstra wrote:
>
>>> I don't hate his per se; but the whole select_idle_sibling() thing is
>>> something that needs looking at.
>>>
>>> There was the task
On 1/14/2019 1:54 PM, Mike Kravetz wrote:
> On 1/14/19 7:35 AM, Steven Sistare wrote:
>> On 1/11/2019 6:28 PM, Mike Kravetz wrote:
>>> On 1/11/19 1:55 PM, Kirill A. Shutemov wrote:
>>>> On Fri, Jan 11, 2019 at 08:10:03PM +, Mike Kravetz wrote:
>>>>>
On 12/24/2018 7:25 AM, Rick Lindsley wrote:
> On 12/06/2018 01:28 PM, Steve Sistare wrote:
>> Add schedstats to measure the effectiveness of searching for idle CPUs
>> and stealing tasks. This is a temporary patch intended for use during
>> development only. SCHEDSTAT_VERSION is bumped to 16,
Hi Peter and Ingo,
I am waiting for one of you to review, ack, or reject this series. I
have addressed all known issues. I have a reviewed-by from Valentin and a
tested-by from Vincent which I will add to v5 if you approve the patch.
- Steve
On 12/6/2018 4:28 PM, Steve Sistare wrote:
> When
On 1/11/2019 6:28 PM, Mike Kravetz wrote:
> On 1/11/19 1:55 PM, Kirill A. Shutemov wrote:
>> On Fri, Jan 11, 2019 at 08:10:03PM +, Mike Kravetz wrote:
>>> At LPC last year, Boaz Harrosh asked why he had to 'jump through hoops'
>>> to get an address returned by mmap() suitably aligned for THP.
On 12/10/2018 12:08 PM, Vincent Guittot wrote:
> On Mon, 10 Dec 2018 at 17:33, Vincent Guittot
> wrote:
>>
>> On Mon, 10 Dec 2018 at 17:29, Steven Sistare
>> wrote:
>>>
>>> On 12/10/2018 11:10 AM, Vincent Guittot wrote:
>>>> Hi Steven
On 12/10/2018 11:10 AM, Vincent Guittot wrote:
> Hi Steven,
>
> On Thu, 6 Dec 2018 at 22:38, Steve Sistare wrote:
>>
>> When a CPU has no more CFS tasks to run, and idle_balance() fails to
>> find a task, then attempt to steal a task from an overloaded CPU in the
>> same LLC. Maintain and use a
On 12/7/2018 3:30 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
>> When a CPU has no more CFS tasks to run, and idle_balance() fails to
>> find a task, then attempt to steal a task from an overloaded CPU in the
>> same LLC. Maintain and use a bitmap of
On 12/7/2018 3:30 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
>> When a CPU has no more CFS tasks to run, and idle_balance() fails to
>> find a task, then attempt to steal a task from an overloaded CPU in the
>> same LLC. Maintain and use a bitmap of
On 12/7/2018 3:21 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -6778,20 +6791,22 @@ static void check_preempt_wakeup(struct rq *rq,
>> struct task_struct *p, int wake_
>> update_misfit_status(NULL, rq);
>>
>> /*
>> - * We
On 12/7/2018 3:21 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -6778,20 +6791,22 @@ static void check_preempt_wakeup(struct rq *rq,
>> struct task_struct *p, int wake_
>> update_misfit_status(NULL, rq);
>>
>> /*
>> - * We
On 12/7/2018 3:20 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -1621,7 +1626,22 @@ static void __sdt_free(const struct cpumask *cpu_map)
>>
>> static int sd_llc_alloc(struct sched_domain *sd)
>> {
>> -/* Allocate sd->shared data
On 12/7/2018 3:20 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -1621,7 +1626,22 @@ static void __sdt_free(const struct cpumask *cpu_map)
>>
>> static int sd_llc_alloc(struct sched_domain *sd)
>> {
>> -/* Allocate sd->shared data
On 12/7/2018 3:20 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -3724,6 +3725,28 @@ static inline void update_misfit_status(struct
>> task_struct *p, struct rq *rq)
>> rq->misfit_task_load = task_h_load(p);
>> }
>>
>> +static void
On 12/7/2018 3:20 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -3724,6 +3725,28 @@ static inline void update_misfit_status(struct
>> task_struct *p, struct rq *rq)
>> rq->misfit_task_load = task_h_load(p);
>> }
>>
>> +static void
On 12/7/2018 6:56 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -6392,6 +6422,7 @@ static int wake_cap(struct task_struct *p, int cpu,
>> int prev_cpu)
>> static int
>> select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag,
On 12/7/2018 6:56 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>> @@ -6392,6 +6422,7 @@ static int wake_cap(struct task_struct *p, int cpu,
>> int prev_cpu)
>> static int
>> select_task_rq_fair(struct task_struct *p, int prev_cpu, int sd_flag,
On 12/7/2018 6:43 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>
> FYI git gets lost when it comes to applying this one on tip/sched/core
> (v4.20-rc5 based), but first applying it on rc1 then rebasing the stack
> on rc5 works fine.
>
> [...]
On 12/7/2018 6:43 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 06/12/2018 21:28, Steve Sistare wrote:
> [...]
>
> FYI git gets lost when it comes to applying this one on tip/sched/core
> (v4.20-rc5 based), but first applying it on rc1 then rebasing the stack
> on rc5 works fine.
>
> [...]
On 12/3/2018 11:56 AM, Valentin Schneider wrote:
> Hi Steve,
> On 26/11/2018 19:06, Steven Sistare wrote:
>> [...]
>>> Mmm I was thinking we could abuse the wrap() and start at
>>> (fls(prev_span) + 1), but we're not guaranteed to have contiguous spans -
>>>
On 12/3/2018 11:56 AM, Valentin Schneider wrote:
> Hi Steve,
> On 26/11/2018 19:06, Steven Sistare wrote:
>> [...]
>>> Mmm I was thinking we could abuse the wrap() and start at
>>> (fls(prev_span) + 1), but we're not guaranteed to have contiguous spans -
>>>
On 11/27/2018 8:19 PM, Omar Sandoval wrote:
> On Tue, Nov 27, 2018 at 10:16:56AM -0500, Steven Sistare wrote:
>> On 11/9/2018 7:50 AM, Steve Sistare wrote:
>>> From: Steve Sistare
>>>
>>> Provide struct sparsemask and functions to manipulate it. A sparsemask
On 11/27/2018 8:19 PM, Omar Sandoval wrote:
> On Tue, Nov 27, 2018 at 10:16:56AM -0500, Steven Sistare wrote:
>> On 11/9/2018 7:50 AM, Steve Sistare wrote:
>>> From: Steve Sistare
>>>
>>> Provide struct sparsemask and functions to manipulate it. A sparsemask
On 11/9/2018 7:50 AM, Steve Sistare wrote:
> From: Steve Sistare
>
> Provide struct sparsemask and functions to manipulate it. A sparsemask is
> a sparse bitmap. It reduces cache contention vs the usual bitmap when many
> threads concurrently set, clear, and visit elements, by reducing the
On 11/9/2018 7:50 AM, Steve Sistare wrote:
> From: Steve Sistare
>
> Provide struct sparsemask and functions to manipulate it. A sparsemask is
> a sparse bitmap. It reduces cache contention vs the usual bitmap when many
> threads concurrently set, clear, and visit elements, by reducing the
On 11/9/2018 11:48 PM, Prakash Sangappa wrote:
> On 9/24/18 10:14 AM, Michal Hocko wrote:
>> On Fri 14-09-18 12:01:18, Steven Sistare wrote:
>>> On 9/14/2018 1:56 AM, Michal Hocko wrote:
>> [...]
>>>> Why does this matter for something that is for anal
On 11/9/2018 11:48 PM, Prakash Sangappa wrote:
> On 9/24/18 10:14 AM, Michal Hocko wrote:
>> On Fri 14-09-18 12:01:18, Steven Sistare wrote:
>>> On 9/14/2018 1:56 AM, Michal Hocko wrote:
>> [...]
>>>> Why does this matter for something that is for anal
On 11/20/2018 7:42 AM, Valentin Schneider wrote:
> On 19/11/2018 17:33, Steven Sistare wrote:
> [...]
>>>
>>> Thinking about misfit stealing, we can't use the sd_llc_shared's because
>>> on big.LITTLE misfit migrations happen across LLC domains.
>>>
>&g
On 11/20/2018 7:42 AM, Valentin Schneider wrote:
> On 19/11/2018 17:33, Steven Sistare wrote:
> [...]
>>>
>>> Thinking about misfit stealing, we can't use the sd_llc_shared's because
>>> on big.LITTLE misfit migrations happen across LLC domains.
>>>
>&g
On 11/12/2018 11:42 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
>> From: Steve Sistare
>>
>> Define and initialize a sparse bitmap of overloaded CPUs, per
>> last-level-cache scheduling domain, for use by the CFS scheduling class.
>> Save a pointer to
On 11/12/2018 11:42 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
>> From: Steve Sistare
>>
>> Define and initialize a sparse bitmap of overloaded CPUs, per
>> last-level-cache scheduling domain, for use by the CFS scheduling class.
>> Save a pointer to
On 11/9/2018 12:38 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
> [...]
>> @@ -482,6 +484,10 @@ static void update_top_cache_domain(int cpu)
>> dirty_sched_domain_sysctl(cpu);
>> destroy_sched_domains(tmp);
>>
>> +sd =
On 11/9/2018 12:38 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
> [...]
>> @@ -482,6 +484,10 @@ static void update_top_cache_domain(int cpu)
>> dirty_sched_domain_sysctl(cpu);
>> destroy_sched_domains(tmp);
>>
>> +sd =
On 11/9/2018 2:07 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
>> Move the update of idle_stamp from idle_balance to the call site in
>> pick_next_task_fair, to prepare for a future patch that adds work to
>> pick_next_task_fair which must be included in
On 11/9/2018 2:07 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 09/11/2018 12:50, Steve Sistare wrote:
>> Move the update of idle_stamp from idle_balance to the call site in
>> pick_next_task_fair, to prepare for a future patch that adds work to
>> pick_next_task_fair which must be included in
Hi folks,
I am attaching the bash helper scripts I used to run and post-process
hackbench
in case you find them useful. They compute the statistics and print a nicely
formatted result:
feat - Enable/disable one or more sched_features.
runmany - run a command many times and print average
Hi folks,
I am attaching the bash helper scripts I used to run and post-process
hackbench
in case you find them useful. They compute the statistics and print a nicely
formatted result:
feat - Enable/disable one or more sched_features.
runmany - run a command many times and print average
On 11/6/2018 1:14 PM, Steven Sistare wrote:
> On 11/6/2018 12:52 PM, Valentin Schneider wrote:
>> Hi Steve,
>>
>> On 05/11/2018 20:07, Steve Sistare wrote:
>> [...]
>>> The patch series is based on kernel 4.19.0-rc7. It compiles, boots, and
>>&g
On 11/6/2018 1:14 PM, Steven Sistare wrote:
> On 11/6/2018 12:52 PM, Valentin Schneider wrote:
>> Hi Steve,
>>
>> On 05/11/2018 20:07, Steve Sistare wrote:
>> [...]
>>> The patch series is based on kernel 4.19.0-rc7. It compiles, boots, and
>>&g
On 11/6/2018 12:52 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 05/11/2018 20:07, Steve Sistare wrote:
> [...]
>> The patch series is based on kernel 4.19.0-rc7. It compiles, boots, and
>> runs with/without each of CONFIG_SCHED_SMT, CONFIG_SMP, CONFIG_SCHED_DEBUG,
>> and CONFIG_PREEMPT. It
On 11/6/2018 12:52 PM, Valentin Schneider wrote:
> Hi Steve,
>
> On 05/11/2018 20:07, Steve Sistare wrote:
> [...]
>> The patch series is based on kernel 4.19.0-rc7. It compiles, boots, and
>> runs with/without each of CONFIG_SCHED_SMT, CONFIG_SMP, CONFIG_SCHED_DEBUG,
>> and CONFIG_PREEMPT. It
On 11/2/2018 7:39 PM, Subhra Mazumdar wrote:
> On 10/22/18 7:59 AM, Steve Sistare wrote:
>> When a CPU has no more CFS tasks to run, and idle_balance() fails to
>> find a task, then attempt to steal a task from an overloaded CPU in the
>> same LLC. Maintain and use a bitmap of overloaded CPUs to
On 11/2/2018 7:39 PM, Subhra Mazumdar wrote:
> On 10/22/18 7:59 AM, Steve Sistare wrote:
>> When a CPU has no more CFS tasks to run, and idle_balance() fails to
>> find a task, then attempt to steal a task from an overloaded CPU in the
>> same LLC. Maintain and use a bitmap of overloaded CPUs to
On 10/22/2018 10:59 AM, Steve Sistare wrote:
> When a CPU has no more CFS tasks to run, and idle_balance() fails to
> find a task, then attempt to steal a task from an overloaded CPU in the
> same LLC. Maintain and use a bitmap of overloaded CPUs to efficiently
> identify candidates. To minimize
On 10/22/2018 10:59 AM, Steve Sistare wrote:
> When a CPU has no more CFS tasks to run, and idle_balance() fails to
> find a task, then attempt to steal a task from an overloaded CPU in the
> same LLC. Maintain and use a bitmap of overloaded CPUs to efficiently
> identify candidates. To minimize
Thanks very much to everyone who has commented on my patch series.
Here are the issues to be addressed in V2 of the series, and the person
that suggested it, or raised the issue that led to it.
Changes for V2:
* Remove stray patch 10 hunk from patch 5 (Valentin)
* Fix "warning: label out
Thanks very much to everyone who has commented on my patch series.
Here are the issues to be addressed in V2 of the series, and the person
that suggested it, or raised the issue that led to it.
Changes for V2:
* Remove stray patch 10 hunk from patch 5 (Valentin)
* Fix "warning: label out
On 10/29/2018 3:34 PM, Valentin Schneider wrote:
> On 26/10/2018 19:28, Steven Sistare wrote:
>> On 10/26/2018 2:04 PM, Valentin Schneider wrote:
> [...]
>>>
>>> I was thinking that perhaps we could have scenarios where some rq's
>>> keep stealing tasks off
On 10/29/2018 3:34 PM, Valentin Schneider wrote:
> On 26/10/2018 19:28, Steven Sistare wrote:
>> On 10/26/2018 2:04 PM, Valentin Schneider wrote:
> [...]
>>>
>>> I was thinking that perhaps we could have scenarios where some rq's
>>> keep stealing tasks off
On 10/26/2018 2:04 PM, Valentin Schneider wrote:
> Hi Steve,
> On 22/10/2018 15:59, Steve Sistare wrote:
>> Define a simpler version of can_migrate_task called can_migrate_task_llc
>> which does not require a struct lb_env argument, and judges whether a
>> migration from one CPU to another within
On 10/26/2018 2:04 PM, Valentin Schneider wrote:
> Hi Steve,
> On 22/10/2018 15:59, Steve Sistare wrote:
>> Define a simpler version of can_migrate_task called can_migrate_task_llc
>> which does not require a struct lb_env argument, and judges whether a
>> migration from one CPU to another within
On 10/25/2018 8:43 AM, Vincent Guittot wrote:
> On Thu, 25 Oct 2018 at 13:29, Steven Sistare
> wrote:
>>
>> On 10/25/2018 3:50 AM, Vincent Guittot wrote:
>>> Hi Steve,
>>>
>>> On Mon, 22 Oct 2018 at 17:10, Steve Sistare
>>> wr
On 10/25/2018 8:43 AM, Vincent Guittot wrote:
> On Thu, 25 Oct 2018 at 13:29, Steven Sistare
> wrote:
>>
>> On 10/25/2018 3:50 AM, Vincent Guittot wrote:
>>> Hi Steve,
>>>
>>> On Mon, 22 Oct 2018 at 17:10, Steve Sistare
>>> wr
On 10/25/2018 9:48 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 22/10/2018 15:59, Steve Sistare wrote:
> [...]
>> +/*
>> + * Try to steal a runnable CFS task from a CPU in the same LLC as @dst_rq,
>> + * and migrate it to @dst_rq. rq_lock is held on entry and return, but
>> + * may be
On 10/25/2018 9:48 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 22/10/2018 15:59, Steve Sistare wrote:
> [...]
>> +/*
>> + * Try to steal a runnable CFS task from a CPU in the same LLC as @dst_rq,
>> + * and migrate it to @dst_rq. rq_lock is held on entry and return, but
>> + * may be
On 10/25/2018 9:47 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 22/10/2018 15:59, Steve Sistare wrote:
> [...]
>> @@ -6740,8 +6744,19 @@ static void check_preempt_wakeup(struct rq *rq,
>> struct task_struct *p, int wake_
>> return p;
>>
>> idle:
>> +/*
>> + * We must set
On 10/25/2018 9:47 AM, Valentin Schneider wrote:
> Hi Steve,
>
> On 22/10/2018 15:59, Steve Sistare wrote:
> [...]
>> @@ -6740,8 +6744,19 @@ static void check_preempt_wakeup(struct rq *rq,
>> struct task_struct *p, int wake_
>> return p;
>>
>> idle:
>> +/*
>> + * We must set
On 10/25/2018 7:31 AM, Valentin Schneider wrote:
>
> On 24/10/2018 20:27, Steven Sistare wrote:
> [...]
>> Hi Valentin,
>>
>> Asymmetric systems could maintain a separate bitmap for misfits; set a bit
>> when a CPU goes on CPU, clear it going off. When a fa
On 10/25/2018 7:31 AM, Valentin Schneider wrote:
>
> On 24/10/2018 20:27, Steven Sistare wrote:
> [...]
>> Hi Valentin,
>>
>> Asymmetric systems could maintain a separate bitmap for misfits; set a bit
>> when a CPU goes on CPU, clear it going off. When a fa
On 10/25/2018 3:50 AM, Vincent Guittot wrote:
> Hi Steve,
>
> On Mon, 22 Oct 2018 at 17:10, Steve Sistare wrote:
>>
>> When a CPU has no more CFS tasks to run, and idle_balance() fails to
>> find a task, then attempt to steal a task from an overloaded CPU in the
>> same LLC. Maintain and use a
On 10/25/2018 3:50 AM, Vincent Guittot wrote:
> Hi Steve,
>
> On Mon, 22 Oct 2018 at 17:10, Steve Sistare wrote:
>>
>> When a CPU has no more CFS tasks to run, and idle_balance() fails to
>> find a task, then attempt to steal a task from an overloaded CPU in the
>> same LLC. Maintain and use a
On 10/24/2018 11:34 AM, Valentin Schneider wrote:
> Hi,
>
> On 22/10/2018 20:07, Steven Sistare wrote:
>> On 10/22/2018 1:04 PM, Peter Zijlstra wrote:
> [...]
>>
>> We could delete idle_balance() and use stealing exclusively for handling
>> new idle. Fo
On 10/24/2018 11:34 AM, Valentin Schneider wrote:
> Hi,
>
> On 22/10/2018 20:07, Steven Sistare wrote:
>> On 10/22/2018 1:04 PM, Peter Zijlstra wrote:
> [...]
>>
>> We could delete idle_balance() and use stealing exclusively for handling
>> new idle. Fo
On 10/22/2018 10:59 AM, Steve Sistare wrote:
[...]
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index f18c416..b7d2070 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -1337,6 +1337,30 @@ static void init_numa_topology_type(void)
> }
> }
>
On 10/22/2018 10:59 AM, Steve Sistare wrote:
[...]
> diff --git a/kernel/sched/topology.c b/kernel/sched/topology.c
> index f18c416..b7d2070 100644
> --- a/kernel/sched/topology.c
> +++ b/kernel/sched/topology.c
> @@ -1337,6 +1337,30 @@ static void init_numa_topology_type(void)
> }
> }
>
1 - 100 of 154 matches
Mail list logo
