[PATCH v19 3/3] vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper

From: Ankit Agrawal NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device for the on-chip GPU that is the logical OS representation of the internal proprietary chip-to-chip cache coherent interconnect. The device is peculiar compared to a real PCI device in that whilst there is a

[PATCH v19 2/3] vfio/pci: rename and export range_intersect_range

From: Ankit Agrawal range_intersect_range determines an overlap between two ranges. If an overlap, the helper function returns the overlapping offset and size. The VFIO PCI variant driver emulates the PCI config space BAR offset registers. These offset may be accessed for read/write with a

[PATCH v19 1/3] vfio/pci: rename and export do_io_rw()

From: Ankit Agrawal do_io_rw() is used to read/write to the device MMIO. The grace hopper VFIO PCI variant driver require this functionality to read/write to its memory. Rename this as vfio_pci_core functions and export as GPL. Reviewed-by: Kevin Tian Reviewed-by: Yishai Hadas Signed-off-by:

[PATCH v19 0/3] vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper

From: Ankit Agrawal NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device for the on-chip GPU that is the logical OS representation of the internal proprietary chip-to-chip cache coherent interconnect. The device is peculiar compared to a real PCI device in that whilst there is a

[PATCH v18 3/3] vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper

From: Ankit Agrawal NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device for the on-chip GPU that is the logical OS representation of the internal proprietary chip-to-chip cache coherent interconnect. The device is peculiar compared to a real PCI device in that whilst there is a

[PATCH v18 2/3] vfio/pci: rename and export range_intersect_range

From: Ankit Agrawal range_intersect_range determines an overlap between two ranges. If an overlap, the helper function returns the overlapping offset and size. The VFIO PCI variant driver emulates the PCI config space BAR offset registers. These offset may be accessed for read/write with a

[PATCH v18 1/3] vfio/pci: rename and export do_io_rw()

From: Ankit Agrawal do_io_rw() is used to read/write to the device MMIO. The grace hopper VFIO PCI variant driver require this functionality to read/write to its memory. Rename this as vfio_pci_core functions and export as GPL. Reviewed-by: Kevin Tian Signed-off-by: Ankit Agrawal ---

[PATCH v18 0/3] vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper

From: Ankit Agrawal NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device for the on-chip GPU that is the logical OS representation of the internal proprietary chip-to-chip cache coherent interconnect. The device is peculiar compared to a real PCI device in that whilst there is a

[PATCH v17 3/3] vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper

From: Ankit Agrawal NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device for the on-chip GPU that is the logical OS representation of the internal proprietary chip-to-chip cache coherent interconnect. The device is peculiar compared to a real PCI device in that whilst there is a

[PATCH v17 2/3] vfio/pci: rename and export range_intesect_range

From: Ankit Agrawal range_intesect_range determines an overlap between two ranges. If an overlap, the helper function returns the overlapping offset and size. The VFIO PCI variant driver emulates the PCI config space BAR offset registers. These offset may be accessed for read/write with a

[PATCH v17 1/3] vfio/pci: rename and export do_io_rw()

From: Ankit Agrawal do_io_rw() is used to read/write to the device MMIO. The grace hopper VFIO PCI variant driver require this functionality to read/write to its memory. Rename this as vfio_pci_core functions and export as GPL. Signed-off-by: Ankit Agrawal ---

[PATCH v17 0/3] vfio/nvgrace-gpu: Add vfio pci variant module for grace hopper

From: Ankit Agrawal NVIDIA's upcoming Grace Hopper Superchip provides a PCI-like device for the on-chip GPU that is the logical OS representation of the internal proprietary chip-to-chip cache coherent interconnect. The device is peculiar compared to a real PCI device in that whilst there is a

Re: [PATCH] RT: Fix special-case exception for preempting the local CPU

; 2) run on CPU task previously ran on > > I think #1 may result in lower latency. But, if the task has lots of > cache warmth the lower wakeup latency may be negated by running on a > 'remote' cpu. Could we use task_hot() routine to find if the task is cache hot? If it isn't, if possible

Re: [PATCH] RT: Fix special-case exception for preempting the local CPU

on a 'remote' cpu. Could we use task_hot() routine to find if the task is cache hot? If it isn't, if possible, we could run on current CPU, else, if possible, on the CPU it last ran on? -- Regards, Ankita Garg ([EMAIL PROTECTED]) Linux Technology Center IBM India Systems Technology Labs

Re: realtime preemption performance difference

> > > - > > > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > > > the body of a message to [EMAIL PROTECTED] > > > More majordomo info at http://vger.kernel.org/majordomo-info.html > > > Please read the FAQ at http://www.tux.o

Re: realtime preemption performance difference

unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > -- Regards, Ankita Garg ([EMAIL PROTECTE

Re: realtime preemption performance difference

of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Regards, Ankita Garg ([EMAIL PROTECTED]) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India - To unsubscribe from

Re: realtime preemption performance difference

PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- Regards, Ankita Garg ([EMAIL PROTECTED]) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India - To unsubscribe from this list: send the line

Re: [PATCH -rt 6/9] spinlock/rt_lock random cleanups

> +# define _write_trylock_irqsave(rwl, flags) \ > + rt_write_trylock_irqsave(rwl, flags) > > # define _read_lock(rwl) rt_read_lock(rwl) > # define _write_lock(rwl)rt_write_lock(rwl) > -- Regards, Ankita Garg ([EMAIL PROTECTED]) Linux Technology Center IBM India Systems &a

Re: [PATCH -rt 6/9] spinlock/rt_lock random cleanups

) -#define _write_trylock_irqsave(rwl, flags) rt_write_trylock_irqsave(rwl, flags) +# define _write_trylock_irqsave(rwl, flags) \ + rt_write_trylock_irqsave(rwl, flags) # define _read_lock(rwl) rt_read_lock(rwl) # define _write_lock(rwl)rt_write_lock(rwl) -- Regards, Ankita Garg

Re: [Question] Hooks for scheduler tracing (CFS)

cally disable hardware interrupts. > > > You just don't want to sleep in the tracing code. [...] Since you > > will likely disable preemption, make sure your tracing code executes > > in a deterministic time. > > Definitely, that has always been the ca

Re: [Question] Hooks for scheduler tracing (CFS)

Hi Ingo, On Thu, Jul 26, 2007 at 01:05:04PM +0200, Ingo Molnar wrote: > > * Ankita Garg <[EMAIL PROTECTED]> wrote: > > > local_irq_save(flags); > > buf = _stp_chan->buf[smp_processor_id()]; > > if (unlikely(buf->o

Re: [Question] Hooks for scheduler tracing (CFS)

On Thu, Jul 26, 2007 at 09:53:53AM +0200, Ingo Molnar wrote: > > * Ankita Garg <[EMAIL PROTECTED]> wrote: > > > > I'd suggest to not put a probe into a preempt-off section - put it > > > to the beginning and to the end of schedule() to capture > &g

Re: [Question] Hooks for scheduler tracing (CFS)

On Thu, Jul 26, 2007 at 09:35:20AM +0200, Ingo Molnar wrote: > > * Ankita Garg <[EMAIL PROTECTED]> wrote: > > > The probe point did get triggered, and soon after that I had the > > following in dmesg, leading to system hang... > > > > BUG: scheduling wh

Re: [Question] Hooks for scheduler tracing (CFS)

t is just one of the many probe points that I tried. In all cases, printing data from within the probe point resulted in the hang (as when I do the printing at the time the script is stopped, everything works just fine!). Any idea why this could be happening? An -rt issue or systemtap bug?? -- Reg

Re: [Question] Hooks for scheduler tracing (CFS)

On Thu, Jul 26, 2007 at 09:35:20AM +0200, Ingo Molnar wrote: * Ankita Garg [EMAIL PROTECTED] wrote: The probe point did get triggered, and soon after that I had the following in dmesg, leading to system hang... BUG: scheduling while atomic: softirq-rcu/3/0x0004/52, CPU#3

Re: [Question] Hooks for scheduler tracing (CFS)

do the printing at the time the script is stopped, everything works just fine!). Any idea why this could be happening? An -rt issue or systemtap bug?? -- Regards, Ankita Garg ([EMAIL PROTECTED]) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India - To unsubscribe

Re: [Question] Hooks for scheduler tracing (CFS)

Hi Ingo, On Thu, Jul 26, 2007 at 01:05:04PM +0200, Ingo Molnar wrote: * Ankita Garg [EMAIL PROTECTED] wrote: local_irq_save(flags); buf = _stp_chan-buf[smp_processor_id()]; if (unlikely(buf-offset + length _stp_chan-subbuf_size)) length

Re: [Question] Hooks for scheduler tracing (CFS)

On Thu, Jul 26, 2007 at 09:53:53AM +0200, Ingo Molnar wrote: * Ankita Garg [EMAIL PROTECTED] wrote: I'd suggest to not put a probe into a preempt-off section - put it to the beginning and to the end of schedule() to capture context-switches. _stp_print_flush() is in the systemtap

Re: [Question] Hooks for scheduler tracing (CFS)

[...] We will review that part of the related code. - FChE -- Regards, Ankita Garg ([EMAIL PROTECTED]) Linux Technology Center IBM India Systems Technology Labs, Bangalore, India - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL

[PREEMPT_RT] [PATCH] Fix BUG: using smp_processor_id() in preemptible [00000000] code: nfsd/2852

tch to fix BUG in drain_array() Signed-off-by: Ankita Garg -- slab.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux-2.6.20-rt8/mm/slab.c === --- linux-2.6.20-rt8.orig/mm/slab.c 2007-04-18 18:41:22.0 +0

[PREEMPT_RT] [PATCH] Fix BUG: using smp_processor_id() in preemptible [00000000] code: nfsd/2852

() Signed-off-by: Ankita Garg ankita2in.ibm.com -- slab.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) Index: linux-2.6.20-rt8/mm/slab.c === --- linux-2.6.20-rt8.orig/mm/slab.c 2007-04-18 18:41:22.0 +0530 +++ linux

[PATCH] oom fix: prevent oom from killing a process with children/sibling unkillable

Looking at oom_kill.c, found that the intention to not kill the selected process if any of its children/siblings has OOM_DISABLE set, is not being met. Signed-off-by: Ankita Garg <[EMAIL PROTECTED]> Index: ankita/linux-2.6.20.1/mm/oom_

[PATCH] oom fix: prevent oom from killing a process with children/sibling unkillable

Looking at oom_kill.c, found that the intention to not kill the selected process if any of its children/siblings has OOM_DISABLE set, is not being met. Signed-off-by: Ankita Garg [EMAIL PROTECTED] Index: ankita/linux-2.6.20.1/mm/oom_kill.c