Displaying 20 results from an estimated 69 matches for "flush_dcache_pages".
Did you mean:
flush_dcache_page
2019 Mar 11
4
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
From: "Michael S. Tsirkin" <mst at redhat.com>
Date: Mon, 11 Mar 2019 09:59:28 -0400
> On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
>>
>> On 2019/3/8 ??10:12, Christoph Hellwig wrote:
>> > On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote:
>> > > This series tries to access virtqueue metadata through kernel virtual
2019 Mar 11
4
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
From: "Michael S. Tsirkin" <mst at redhat.com>
Date: Mon, 11 Mar 2019 09:59:28 -0400
> On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
>>
>> On 2019/3/8 ??10:12, Christoph Hellwig wrote:
>> > On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote:
>> > > This series tries to access virtqueue metadata through kernel virtual
2019 Mar 12
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On 2019/3/12 ??1:14, James Bottomley wrote:
> On Tue, 2019-03-12 at 10:59 +0800, Jason Wang wrote:
>> On 2019/3/12 ??2:14, David Miller wrote:
>>> From: "Michael S. Tsirkin" <mst at redhat.com>
>>> Date: Mon, 11 Mar 2019 09:59:28 -0400
>>>
>>>> On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
>>>>> On
2019 Mar 12
9
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote:
>
> On 2019/3/12 ??2:14, David Miller wrote:
> > From: "Michael S. Tsirkin" <mst at redhat.com>
> > Date: Mon, 11 Mar 2019 09:59:28 -0400
> >
> > > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
> > > > On 2019/3/8 ??10:12, Christoph Hellwig wrote:
> > >
2019 Mar 12
9
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote:
>
> On 2019/3/12 ??2:14, David Miller wrote:
> > From: "Michael S. Tsirkin" <mst at redhat.com>
> > Date: Mon, 11 Mar 2019 09:59:28 -0400
> >
> > > On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
> > > > On 2019/3/8 ??10:12, Christoph Hellwig wrote:
> > >
2019 Apr 09
2
[PATCH net] vhost: flush dcache page when logging dirty pages
We set dirty bit through setting up kmaps and access them through
kernel virtual address, this may result alias in virtually tagged
caches that require a dcache flush afterwards.
Cc: Christoph Hellwig <hch at infradead.org>
Cc: James Bottomley <James.Bottomley at HansenPartnership.com>
Cc: Andrea Arcangeli <aarcange at redhat.com>
Fixes: 3a4d5c94e9593 ("vhost_net: a
2019 Apr 09
2
[PATCH net] vhost: flush dcache page when logging dirty pages
We set dirty bit through setting up kmaps and access them through
kernel virtual address, this may result alias in virtually tagged
caches that require a dcache flush afterwards.
Cc: Christoph Hellwig <hch at infradead.org>
Cc: James Bottomley <James.Bottomley at HansenPartnership.com>
Cc: Andrea Arcangeli <aarcange at redhat.com>
Fixes: 3a4d5c94e9593 ("vhost_net: a
2019 Mar 12
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Tue, Mar 12, 2019 at 08:46:50AM -0700, James Bottomley wrote:
> On Tue, 2019-03-12 at 07:54 -0400, Michael S. Tsirkin wrote:
> > On Tue, Mar 12, 2019 at 03:17:00PM +0800, Jason Wang wrote:
> > >
> > > On 2019/3/12 ??????11:52, Michael S. Tsirkin wrote:
> > > > On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote:
> [...]
> > > At least
2019 Mar 12
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Tue, Mar 12, 2019 at 02:19:15PM -0700, James Bottomley wrote:
> I mean in the sequence
>
> flush_dcache_page(page);
> flush_dcache_page(page);
>
> The first flush_dcache_page did all the work and the second it a
> tightly pipelined no-op. That's what I mean by there not really being
> a double hit.
Ok I wasn't sure it was clear there was a double (profiling)
2019 Mar 14
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Wed, Mar 13, 2019 at 09:37:08AM -0700, James Bottomley wrote:
> On Wed, 2019-03-13 at 09:05 -0700, Christoph Hellwig wrote:
> > On Tue, Mar 12, 2019 at 01:53:37PM -0700, James Bottomley wrote:
> > > I've got to say: optimize what? What code do we ever have in the
> > > kernel that kmap's a page and then doesn't do anything with it? You
> > > can
2010 Dec 07
9
[PATCH] Btrfs: pwrite blocked when writing from the mmaped buffer of the same page
This problem is found in meego testing:
http://bugs.meego.com/show_bug.cgi?id=6672
A file in btrfs is mmaped and the mmaped buffer is passed to pwrite to write to the same page
of the same file. In btrfs_file_aio_write(), the pages is locked by prepare_pages(). So when
btrfs_copy_from_user() is called, page fault happens and the same page needs to be locked again
in filemap_fault(). The fix is to
2019 Mar 12
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On 2019/3/12 ??2:14, David Miller wrote:
> From: "Michael S. Tsirkin" <mst at redhat.com>
> Date: Mon, 11 Mar 2019 09:59:28 -0400
>
>> On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
>>> On 2019/3/8 ??10:12, Christoph Hellwig wrote:
>>>> On Wed, Mar 06, 2019 at 02:18:07AM -0500, Jason Wang wrote:
>>>>> This series tries
2019 Mar 12
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On 2019/3/12 ??11:52, Michael S. Tsirkin wrote:
> On Tue, Mar 12, 2019 at 10:59:09AM +0800, Jason Wang wrote:
>> On 2019/3/12 ??2:14, David Miller wrote:
>>> From: "Michael S. Tsirkin" <mst at redhat.com>
>>> Date: Mon, 11 Mar 2019 09:59:28 -0400
>>>
>>>> On Mon, Mar 11, 2019 at 03:13:17PM +0800, Jason Wang wrote:
>>>>>
2019 Apr 09
0
[PATCH net] vhost: flush dcache page when logging dirty pages
On Tue, Apr 09, 2019 at 12:16:47PM +0800, Jason Wang wrote:
> We set dirty bit through setting up kmaps and access them through
> kernel virtual address, this may result alias in virtually tagged
> caches that require a dcache flush afterwards.
>
> Cc: Christoph Hellwig <hch at infradead.org>
> Cc: James Bottomley <James.Bottomley at HansenPartnership.com>
> Cc:
2023 Mar 02
1
[PATCH] ocfs2: Fix data corruption after failed write
When buffered write fails to copy data into underlying page cache page,
ocfs2_write_end_nolock() just zeroes out and dirties the page. This can
leave dirty page beyond EOF and if page writeback tries to write this
page before write succeeds and expands i_size, page gets into
inconsistent state where page dirty bit is clear but buffer dirty bits
stay set resulting in page data never getting written
2019 Mar 12
0
[RFC PATCH V2 0/5] vhost: accelerate metadata access through vmap()
On Tue, Mar 12, 2019 at 01:53:37PM -0700, James Bottomley wrote:
> I've got to say: optimize what? What code do we ever have in the
> kernel that kmap's a page and then doesn't do anything with it? You can
> guarantee that on kunmap the page is either referenced (needs
> invalidating) or updated (needs flushing). The in-kernel use of kmap is
> always
>
> kmap
2019 Sep 06
0
[vhost:linux-next 13/15] arch/ia64/include/asm/page.h:51:23: warning: "hpage_shift" is not defined, evaluates to 0
tree: https://kernel.googlesource.com/pub/scm/linux/kernel/git/mst/vhost.git linux-next
head: c5db5a8d998da36ada7287aa53b4ed501a0a2b2b
commit: b1b0d638e6f93b91cf34585350bb00035d066989 [13/15] mm: Introduce Reported pages
config: ia64-defconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.4.0
reproduce:
wget
2023 Mar 20
2
FAILED: patch "[PATCH] ocfs2: fix data corruption after failed write" failed to apply to 5.10-stable tree
The patch below does not apply to the 5.10-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable at vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
2023 Mar 20
1
FAILED: patch "[PATCH] ocfs2: fix data corruption after failed write" failed to apply to 4.19-stable tree
The patch below does not apply to the 4.19-stable tree.
If someone wants it applied there, or to any other stable or longterm
tree, then please email the backport, including the original git commit
id to <stable at vger.kernel.org>.
To reproduce the conflict and resubmit, you may use the following commands:
git fetch https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/
2013 Nov 27
0
[PATCH 07/25] block: Convert bio_for_each_segment() to bvec_iter
...mem += vec.bv_len;
+ transfered += vec.bv_len;
}
bio_endio(bio, 0);
}
diff --git a/block/blk-core.c b/block/blk-core.c
index 5c2ab2c..5da8e90 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -2746,10 +2746,10 @@ void blk_rq_bio_prep(struct request_queue *q, struct request *rq,
void rq_flush_dcache_pages(struct request *rq)
{
struct req_iterator iter;
- struct bio_vec *bvec;
+ struct bio_vec bvec;
rq_for_each_segment(bvec, rq, iter)
- flush_dcache_page(bvec->bv_page);
+ flush_dcache_page(bvec.bv_page);
}
EXPORT_SYMBOL_GPL(rq_flush_dcache_pages);
#endif
diff --git a/block/blk-merge.c...