Displaying 20 results from an estimated 23 matches for "mem_sect".
Did you mean:
mem_set
2019 Aug 08
2
[PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
...vice is still attached/enabled that check is invalidated at
> put_dev_pagemap().
>
> If it's the former case, validating ZONE_DEVICE pfns, I imagine we can
> do something cheaper with a helper that is on the order of the same
> cost as pfn_valid(). I.e. replace PTE_DEVMAP with a mem_section flag
> or something similar.
The hmm literally never dereferences the pgmap, so validity checking is
the only explanation for it.
> > + /*
> > + * We do put_dev_pagemap() here so that we can leverage
> > + * get_dev_pagemap() opt...
2019 Aug 07
2
[PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
On Tue, Aug 06, 2019 at 07:05:42PM +0300, Christoph Hellwig wrote:
> There is only a single place where the pgmap is passed over a function
> call, so replace it with local variables in the places where we deal
> with the pgmap.
>
> Signed-off-by: Christoph Hellwig <hch at lst.de>
> mm/hmm.c | 62 ++++++++++++++++++++++++--------------------------------
> 1 file
2019 Aug 14
0
[PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
...nabled that check is invalidated at
> > put_dev_pagemap().
> >
> > If it's the former case, validating ZONE_DEVICE pfns, I imagine we can
> > do something cheaper with a helper that is on the order of the same
> > cost as pfn_valid(). I.e. replace PTE_DEVMAP with a mem_section flag
> > or something similar.
>
> The hmm literally never dereferences the pgmap, so validity checking is
> the only explanation for it.
>
> > > + /*
> > > + * We do put_dev_pagemap() here so that we can leverage
> > > +...
2019 Aug 07
0
[PATCH 04/15] mm: remove the pgmap field from struct hmm_vma_walk
...nt is to make sure
the device is still attached/enabled that check is invalidated at
put_dev_pagemap().
If it's the former case, validating ZONE_DEVICE pfns, I imagine we can
do something cheaper with a helper that is on the order of the same
cost as pfn_valid(). I.e. replace PTE_DEVMAP with a mem_section flag
or something similar.
>
> > }
> > pfns[i] = hmm_device_entry_from_pfn(range, pfn) | cpu_flags;
> > }
> > - if (hmm_vma_walk->pgmap) {
> > - put_dev_pagemap(hmm_vma_walk->pgmap);
> > -...
2009 Aug 24
1
[PATCH 1/8] blkio-cgroup-v11: Introduction
Hi all,
This is a new release of blkio-cgroup v11.
Changes:
- The function cgroup_get_from_page() is added which determines to
which cgroup a given page belongs. This function is introduced from
Vivek's io-controller patch. Thanks Vivek.
- Fix a type mismatch of the refcount of io_context. The refcount has
been changed to atomic_long_t.
This patch can be applied to 2.6.31-rc7.
The
2009 Aug 24
1
[PATCH 1/8] blkio-cgroup-v11: Introduction
Hi all,
This is a new release of blkio-cgroup v11.
Changes:
- The function cgroup_get_from_page() is added which determines to
which cgroup a given page belongs. This function is introduced from
Vivek's io-controller patch. Thanks Vivek.
- Fix a type mismatch of the refcount of io_context. The refcount has
been changed to atomic_long_t.
This patch can be applied to 2.6.31-rc7.
The
2009 Aug 24
1
[PATCH 1/8] blkio-cgroup-v11: Introduction
Hi all,
This is a new release of blkio-cgroup v11.
Changes:
- The function cgroup_get_from_page() is added which determines to
which cgroup a given page belongs. This function is introduced from
Vivek's io-controller patch. Thanks Vivek.
- Fix a type mismatch of the refcount of io_context. The refcount has
been changed to atomic_long_t.
This patch can be applied to 2.6.31-rc7.
The
2009 Jul 28
1
[PATCH 1/7] blkio-cgroup-v10: Introduction
Hi all,
This is a new release of blkio-cgroup v10. This release reduces
IO tracking overhead and fixes an issue that could cause a deadlock
since lock_page_cgroup() is no longer used.
Thank you KAMEZAWA-san for your suggestions and pointing out the issue.
This patch can be applied to 2.6.31-rc3-mmotm0716 and 2.6.31-rc4.
The list of the patches:
[PATCH 1/7] blkio-cgroup-v10: Introduction
2009 Jul 28
1
[PATCH 1/7] blkio-cgroup-v10: Introduction
Hi all,
This is a new release of blkio-cgroup v10. This release reduces
IO tracking overhead and fixes an issue that could cause a deadlock
since lock_page_cgroup() is no longer used.
Thank you KAMEZAWA-san for your suggestions and pointing out the issue.
This patch can be applied to 2.6.31-rc3-mmotm0716 and 2.6.31-rc4.
The list of the patches:
[PATCH 1/7] blkio-cgroup-v10: Introduction
2009 Jul 28
1
[PATCH 1/7] blkio-cgroup-v10: Introduction
Hi all,
This is a new release of blkio-cgroup v10. This release reduces
IO tracking overhead and fixes an issue that could cause a deadlock
since lock_page_cgroup() is no longer used.
Thank you KAMEZAWA-san for your suggestions and pointing out the issue.
This patch can be applied to 2.6.31-rc3-mmotm0716 and 2.6.31-rc4.
The list of the patches:
[PATCH 1/7] blkio-cgroup-v10: Introduction
2009 Apr 16
1
[PATCH 1/5] bio-cgroup: Introduction
Hi all,
This is a new release of bio-cgroup which provides an IO tracking
mechanism. The patches can be applied to the kernel 2.6.30-rc1 and you
can also download them from the following site.
http://people.valinux.co.jp/~ryov/bio-cgroup/
What's bio-cgroup all about?
============================
With this feature, you can determine the owners of any type of
I/Os. This makes
2009 Apr 16
1
[PATCH 1/5] bio-cgroup: Introduction
Hi all,
This is a new release of bio-cgroup which provides an IO tracking
mechanism. The patches can be applied to the kernel 2.6.30-rc1 and you
can also download them from the following site.
http://people.valinux.co.jp/~ryov/bio-cgroup/
What's bio-cgroup all about?
============================
With this feature, you can determine the owners of any type of
I/Os. This makes
2009 Apr 16
1
[PATCH 1/5] bio-cgroup: Introduction
Hi all,
This is a new release of bio-cgroup which provides an IO tracking
mechanism. The patches can be applied to the kernel 2.6.30-rc1 and you
can also download them from the following site.
http://people.valinux.co.jp/~ryov/bio-cgroup/
What's bio-cgroup all about?
============================
With this feature, you can determine the owners of any type of
I/Os. This makes
2009 Apr 28
1
[PATCH 1/7] blkio-cgroup: Introduction
Hi all,
This is a new release of blkio-cgroup which provides an IO tracking
mechanism. You can also download this series of patches from
http://people.valinux.co.jp/~ryov/blkio-cgroup/
Changes from the previous release
=================================
- bio-cgroup renamed to blkio-cgroup.
- Use part of page_cgroup->flags to store the blkio-cgroup ID.
This code is taken from Andrea's
2009 Apr 28
1
[PATCH 1/7] blkio-cgroup: Introduction
Hi all,
This is a new release of blkio-cgroup which provides an IO tracking
mechanism. You can also download this series of patches from
http://people.valinux.co.jp/~ryov/blkio-cgroup/
Changes from the previous release
=================================
- bio-cgroup renamed to blkio-cgroup.
- Use part of page_cgroup->flags to store the blkio-cgroup ID.
This code is taken from Andrea's
2009 Apr 28
1
[PATCH 1/7] blkio-cgroup: Introduction
Hi all,
This is a new release of blkio-cgroup which provides an IO tracking
mechanism. You can also download this series of patches from
http://people.valinux.co.jp/~ryov/blkio-cgroup/
Changes from the previous release
=================================
- bio-cgroup renamed to blkio-cgroup.
- Use part of page_cgroup->flags to store the blkio-cgroup ID.
This code is taken from Andrea's
2020 Sep 11
13
[PATCH v4 0/8] selective merging of system ram resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2020 Sep 11
13
[PATCH v4 0/8] selective merging of system ram resources
Some add_memory*() users add memory in small, contiguous memory blocks.
Examples include virtio-mem, hyper-v balloon, and the XEN balloon.
This can quickly result in a lot of memory resources, whereby the actual
resource boundaries are not of interest (e.g., it might be relevant for
DIMMs, exposed via /proc/iomem to user space). We really want to merge
added resources in this scenario where
2012 Jun 25
4
[RFC V2 PATCH 0/4] Multiqueue support for tap and virtio-net/vhost
Hello all:
This seires is an update of last version of multiqueue support to add multiqueue
capability to both tap and virtio-net.
Some kinds of tap backends has (macvatp in linux) or would (tap) support
multiqueue. In such kind of tap backend, each file descriptor of a tap is a
qeueu and ioctls were prodived to attach an exist tap file descriptor to the
tun/tap device. So the patch let qemu to
2012 Jun 25
4
[RFC V2 PATCH 0/4] Multiqueue support for tap and virtio-net/vhost
Hello all:
This seires is an update of last version of multiqueue support to add multiqueue
capability to both tap and virtio-net.
Some kinds of tap backends has (macvatp in linux) or would (tap) support
multiqueue. In such kind of tap backend, each file descriptor of a tap is a
qeueu and ioctls were prodived to attach an exist tap file descriptor to the
tun/tap device. So the patch let qemu to