Displaying 16 results from an estimated 16 matches for "exposting".
Did you mean:
exposing
2005 May 04
1
Avoiding Sweave formula cut's?
Hi,
anybody know a possibilities how i could avoid less nicely cut's in
function calls with sweave like:
randomForest(x = RELSHIP ~ ., data = R_RELSHIP[splitR_RELSHIP == 1,
], importance = T, n(*here is the cut in the pdf*)
tree = 1000, na.action = na.omit)
Until now i add expost linebreaks in the *.tex file, but with dozend of
models it might be painfuel for my hands.
Many
2023 Jan 06
2
[PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
On Fri, Jan 06, 2023 at 05:15:28PM +0000, Robin Murphy wrote:
> On 2023-01-06 16:42, Jason Gunthorpe wrote:
> > The internal mechanisms support this, but instead of exposting the gfp to
> > the caller it wrappers it into iommu_map() and iommu_map_atomic()
> >
> > Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
>
> FWIW, since we *do* have two variants already, I think I'd have a mild
> preference for leaving the regular...
2023 Jan 06
2
[PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
On Fri, Jan 06, 2023 at 05:15:28PM +0000, Robin Murphy wrote:
> On 2023-01-06 16:42, Jason Gunthorpe wrote:
> > The internal mechanisms support this, but instead of exposting the gfp to
> > the caller it wrappers it into iommu_map() and iommu_map_atomic()
> >
> > Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
>
> FWIW, since we *do* have two variants already, I think I'd have a mild
> preference for leaving the regular...
2023 Jan 06
3
[PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
arch/arm/mm/dma-mapping.c | 11 +++++++----
.../gpu/drm/nouveau/nvkm/su...
2023 Jan 06
3
[PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
arch/arm/mm/dma-mapping.c | 11 +++++++----
.../gpu/drm/nouveau/nvkm/su...
2023 Jan 06
3
[PATCH 1/8] iommu: Add a gfp parameter to iommu_map()
The internal mechanisms support this, but instead of exposting the gfp to
the caller it wrappers it into iommu_map() and iommu_map_atomic()
Fix this instead of adding more variants for GFP_KERNEL_ACCOUNT.
Signed-off-by: Jason Gunthorpe <jgg at nvidia.com>
---
arch/arm/mm/dma-mapping.c | 11 +++++++----
.../gpu/drm/nouveau/nvkm/su...
2008 Oct 16
3
Alternatives to programmatically calling the rsync binary a lot
Dear list, I'd like to have your expertise opinion on following issue.
Out of a concrete need we developed an application that will rsync any
changes on a local directory structure to a remove system the moment they
happen using the linux kernel watch feature. This is in our opinion much
more elegant compared to invoking rsync every x seconds/minutes from cron,
or having to use a special
2007 Nov 10
2
[PATCH] Change virtio_pci to use a shared memory area for config
This patch changes virtio_pci to use a shared memory area for virtio config
info instead of using the PCI configuration space. This is closer semantically
to what the virtio API exposes and is it a lot easier to implement on both
ends.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index eb9a8e0..7e6e453 100644
2007 Nov 10
2
[PATCH] Change virtio_pci to use a shared memory area for config
This patch changes virtio_pci to use a shared memory area for virtio config
info instead of using the PCI configuration space. This is closer semantically
to what the virtio API exposes and is it a lot easier to implement on both
ends.
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
diff --git a/drivers/virtio/virtio_pci.c b/drivers/virtio/virtio_pci.c
index eb9a8e0..7e6e453 100644
2023 Jan 06
8
[PATCH 0/8] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first
2023 Jan 06
8
[PATCH 0/8] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first
2023 Jan 06
8
[PATCH 0/8] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first
2012 Dec 10
26
[PATCH 00/11] Add virtual EPT support Xen.
From: Zhang Xiantao <xiantao.zhang@intel.com>
With virtual EPT support, L1 hyerpvisor can use EPT hardware
for L2 guest''s memory virtualization. In this way, L2 guest''s
performance can be improved sharply. According to our testing,
some benchmarks can show > 5x performance gain.
Signed-off-by: Zhang Xiantao <xiantao.zhang@intel.com>
Zhang Xiantao (11):
2023 Jan 18
10
[PATCH v2 00/10] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first
2023 Jan 23
11
[PATCH v3 00/10] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first
2023 Jan 23
11
[PATCH v3 00/10] Let iommufd charge IOPTE allocations to the memory cgroup
iommufd follows the same design as KVM and uses memory cgroups to limit
the amount of kernel memory a iommufd file descriptor can pin down. The
various internal data structures already use GFP_KERNEL_ACCOUNT to charge
its own memory.
However, one of the biggest consumers of kernel memory is the IOPTEs
stored under the iommu_domain and these allocations are not tracked.
This series is the first