On Thu, Sep 29, 2016 at 09:03:43PM -0600, Ross Zwisler wrote:
> On Fri, Sep 30, 2016 at 09:43:45AM +1000, Dave Chinner wrote:
> > Finally: none of the patches in your tree have reviewed-by tags.
> > That says to me that none of this code has been reviewed yet.
> > Rev
On Thu, Sep 29, 2016 at 09:03:43PM -0600, Ross Zwisler wrote:
> On Fri, Sep 30, 2016 at 09:43:45AM +1000, Dave Chinner wrote:
> > Finally: none of the patches in your tree have reviewed-by tags.
> > That says to me that none of this code has been reviewed yet.
> > Rev
one tree to avoid issues
like this.
>
> Changes since v3:
> - Corrected dax iomap code namespace for functions defined in fs/dax.c.
>(Dave Chinner)
> - Added leading "dax" namespace to new static functions in fs/dax.c.
>(Dave Chinner)
> - Made all DAX
one tree to avoid issues
like this.
>
> Changes since v3:
> - Corrected dax iomap code namespace for functions defined in fs/dax.c.
>(Dave Chinner)
> - Added leading "dax" namespace to new static functions in fs/dax.c.
>(Dave Chinner)
> - Made all DAX
esting of the DAX
changes (apart from the cursor comments I've already made) because
of the huge pile of XFS reflink changes I've got ot get through
first. However, I've already got the iomap dax bits in the XFS tree
so I can pull everything through there if review and testing is
covered otherwise..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
esting of the DAX
changes (apart from the cursor comments I've already made) because
of the huge pile of XFS reflink changes I've got ot get through
first. However, I've already got the iomap dax bits in the XFS tree
so I can pull everything through there if review and testing is
covered otherwise..
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
;vm_file->f_mapping;
> + unsigned long pmd_addr = address & PMD_MASK;
> + bool write = flags & FAULT_FLAG_WRITE;
> + struct inode *inode = mapping->host;
> + struct iomap iomap = { 0 };
> + int error, result = 0;
> + pgoff_t size, pgoff;
>
ing;
> + unsigned long pmd_addr = address & PMD_MASK;
> + bool write = flags & FAULT_FLAG_WRITE;
> + struct inode *inode = mapping->host;
> + struct iomap iomap = { 0 };
> + int error, result = 0;
> + pgoff_t size, pgoff;
> + struct vm_fault vmf;
> + void *entry;
> + loff_t pos;
> +
> + /* dax pmd mappings require pfn_t_devmap() */
> + if (!IS_ENABLED(CONFIG_FS_DAX_PMD))
> + return VM_FAULT_FALLBACK;
So we build all this stuff in, even if CONFIG_FS_DAX_PMD=n?
Shouldn't we just have a simple function that returns
VM_FAULT_FALLBACK when CONFIG_FS_DAX_PMD=n?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
ould it be better to put a comment mentioning this here? So as the
years go by, this reminds people not to bother trying to implement
it?
/*
* .pmd_fault is not supported for DAX because allocation in ext2
* cannot be reliably aligned to huge page sizes and so pmd faults
* will always fail and fail back to regular faults.
*/
--
Dave Chinner
da...@fromorbit.com
omment mentioning this here? So as the
years go by, this reminds people not to bother trying to implement
it?
/*
* .pmd_fault is not supported for DAX because allocation in ext2
* cannot be reliably aligned to huge page sizes and so pmd faults
* will always fail and fail back to regular faults.
*/
--
Dave Chinner
da...@fromorbit.com
> > SCRATCH_MNT=SCRATCH \
> > ./check `grep -il freeze tests/*/???`
>
> You can run either:
>
> ./check -g freeze
>
> to check just the freezing tests or
>
> ./check
Better for regression testing is:
check -g auto
so that is skips all the tests that are broken or likely to crash
the machine on some debug check.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
> > SCRATCH_MNT=SCRATCH \
> > ./check `grep -il freeze tests/*/???`
>
> You can run either:
>
> ./check -g freeze
>
> to check just the freezing tests or
>
> ./check
Better for regression testing is:
check -g auto
so that is skips all the tests that are broken or likely to crash
the machine on some debug check.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Sun, Sep 25, 2016 at 06:21:05PM -0700, Linus Torvalds wrote:
> Thanks, applied.
>
> I did happen to notice:
>
> On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner <da...@fromorbit.com> wrote:
> >
> > ./include/linux/pagemap.h: In function ¿fault_in_multipag
On Sun, Sep 25, 2016 at 06:21:05PM -0700, Linus Torvalds wrote:
> Thanks, applied.
>
> I did happen to notice:
>
> On Sun, Sep 25, 2016 at 4:57 PM, Dave Chinner wrote:
> >
> > ./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
> > ./incl
From: Dave Chinner <dchin...@redhat.com>
When building XFS with -Werror, it now fails with:
./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used
[-Werror=unused-but-set-variable]
volatile
From: Dave Chinner
When building XFS with -Werror, it now fails with:
./include/linux/pagemap.h: In function ¿fault_in_multipages_readable¿:
./include/linux/pagemap.h:602:16: error: variable ¿c¿ set but not used
[-Werror=unused-but-set-variable]
volatile char c
On Mon, Sep 26, 2016 at 09:22:45AM +1000, Dave Chinner wrote:
> Hi Folks,
>
> I just upgraded a test VM from 4.8-rc6 to 4.8-rc7, and went to run:
>
> # perf_4.7 top -g -U
>
> inside the VM - the kernel oops with the trace below. The perf
> binary was built fr
On Mon, Sep 26, 2016 at 09:22:45AM +1000, Dave Chinner wrote:
> Hi Folks,
>
> I just upgraded a test VM from 4.8-rc6 to 4.8-rc7, and went to run:
>
> # perf_4.7 top -g -U
>
> inside the VM - the kernel oops with the trace below. The perf
> binary was built fr
0018
[ 16.535644] ---[ end trace 61a930b5078051b0 ]---
[ 16.535644] Kernel panic - not syncing: Fatal exception in interrupt
[ 16.535833] Kernel Offset: disabled
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
0018
[ 16.535644] ---[ end trace 61a930b5078051b0 ]---
[ 16.535644] Kernel panic - not syncing: Fatal exception in interrupt
[ 16.535833] Kernel Offset: disabled
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
nobody has been able to reproduce it exactly
outside of the reaim benchmark. We've reproduced other, similar
issues, and the fixes for those are queued for the 4.9 window.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
nobody has been able to reproduce it exactly
outside of the reaim benchmark. We've reproduced other, similar
issues, and the fixes for those are queued for the 4.9 window.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Sep 15, 2016 at 07:04:27PM -0700, Dan Williams wrote:
> On Thu, Sep 15, 2016 at 6:24 PM, Dave Chinner <da...@fromorbit.com> wrote:
> > On Thu, Sep 15, 2016 at 05:16:42PM -0700, Dan Williams wrote:
> >> On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner <da...@fromorbi
On Thu, Sep 15, 2016 at 07:04:27PM -0700, Dan Williams wrote:
> On Thu, Sep 15, 2016 at 6:24 PM, Dave Chinner wrote:
> > On Thu, Sep 15, 2016 at 05:16:42PM -0700, Dan Williams wrote:
> >> On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner wrote:
> >> > On Thu, Sep 15,
On Thu, Sep 15, 2016 at 05:16:42PM -0700, Dan Williams wrote:
> On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner <da...@fromorbit.com> wrote:
> > On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Williams wrote:
> >> On Thu, Sep 15, 2016 at 1:26 AM, Christoph Hellwig <h...@l
On Thu, Sep 15, 2016 at 05:16:42PM -0700, Dan Williams wrote:
> On Thu, Sep 15, 2016 at 4:07 PM, Dave Chinner wrote:
> > On Thu, Sep 15, 2016 at 10:01:03AM -0700, Dan Williams wrote:
> >> On Thu, Sep 15, 2016 at 1:26 AM, Christoph Hellwig wrote:
> >> > On Wed, Se
086
@@ -96,7 +96,8 @@ _scratch_mount
echo "+ modify files"
for x in `seq 1 64`; do
- $XFS_IO_PROG -f -c "pwrite -S 0x62 0 ${blksz}" "${TESTFILE}.${x}" >>
$seqres.full
+ $XFS_IO_PROG -f -c "pwrite -S 0x62 0 ${blksz}" "${TESTFILE}.${x}" \
+ >> $seqres.full 2>&1
done
umount "${SCRATCH_MNT}"
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
7 +96,8 @@ _scratch_mount
echo "+ modify files"
for x in `seq 1 64`; do
- $XFS_IO_PROG -f -c "pwrite -S 0x62 0 ${blksz}" "${TESTFILE}.${x}" >>
$seqres.full
+ $XFS_IO_PROG -f -c "pwrite -S 0x62 0 ${blksz}" "${TESTFILE}.${x}" \
+ >> $seqres.full 2>&1
done
umount "${SCRATCH_MNT}"
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Thu, Sep 15, 2016 at 09:42:22PM +1000, Nicholas Piggin wrote:
> On Thu, 15 Sep 2016 20:32:10 +1000
> Dave Chinner <da...@fromorbit.com> wrote:
> >
> > You still haven't described anything about what a per-block flag
> > design is supposed to look like :/
>
On Thu, Sep 15, 2016 at 09:42:22PM +1000, Nicholas Piggin wrote:
> On Thu, 15 Sep 2016 20:32:10 +1000
> Dave Chinner wrote:
> >
> > You still haven't described anything about what a per-block flag
> > design is supposed to look like :/
>
> For the API, or impl
On Thu, Sep 15, 2016 at 01:49:45PM +1000, Nicholas Piggin wrote:
> On Thu, 15 Sep 2016 12:31:33 +1000
> Dave Chinner <da...@fromorbit.com> wrote:
>
> > On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote:
> > > On Wed, 14 Sep 2016 17:39:02 +1000
> >
On Thu, Sep 15, 2016 at 01:49:45PM +1000, Nicholas Piggin wrote:
> On Thu, 15 Sep 2016 12:31:33 +1000
> Dave Chinner wrote:
>
> > On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote:
> > > On Wed, 14 Sep 2016 17:39:02 +1000
> > Sure, but one first has t
On Wed, Sep 14, 2016 at 10:55:03PM -0700, Darrick J. Wong wrote:
> On Mon, Sep 12, 2016 at 11:40:35AM +1000, Dave Chinner wrote:
> > On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote:
> > > On Wed, Sep 07, 2016 at 09:32:36PM -0700, Dan Williams wrote:
> &
On Wed, Sep 14, 2016 at 10:55:03PM -0700, Darrick J. Wong wrote:
> On Mon, Sep 12, 2016 at 11:40:35AM +1000, Dave Chinner wrote:
> > On Thu, Sep 08, 2016 at 04:56:36PM -0600, Ross Zwisler wrote:
> > > On Wed, Sep 07, 2016 at 09:32:36PM -0700, Dan Williams wrote:
> &
On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote:
> On Wed, 14 Sep 2016 17:39:02 +1000
> Dave Chinner <da...@fromorbit.com> wrote:
> > Ok, looking back over your example, you seem to be suggesting a new
> > page fault behaviour is required from files
On Wed, Sep 14, 2016 at 08:19:36PM +1000, Nicholas Piggin wrote:
> On Wed, 14 Sep 2016 17:39:02 +1000
> Dave Chinner wrote:
> > Ok, looking back over your example, you seem to be suggesting a new
> > page fault behaviour is required from filesystems that has not been
> >
On Tue, Sep 13, 2016 at 11:53:11AM +1000, Nicholas Piggin wrote:
> On Tue, 13 Sep 2016 07:34:36 +1000
> Dave Chinner <da...@fromorbit.com> wrote:
> But let me understand your example in the absence of that.
>
> - Application mmaps a file, faults in block 0
> - FS allocates
On Tue, Sep 13, 2016 at 11:53:11AM +1000, Nicholas Piggin wrote:
> On Tue, 13 Sep 2016 07:34:36 +1000
> Dave Chinner wrote:
> But let me understand your example in the absence of that.
>
> - Application mmaps a file, faults in block 0
> - FS allocates block, creates mappin
bit;
> + mask = ((1U << (end_bit - bit)) - 1) << bit;
> *wordp |= mask;
> wordp++;
> bits_set = end_bit - bit;
This patch is whitespace damaged and fails to apply. I've fixed it
up as this is a trivial change. However, please fix the problem
before you submit more patches.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
; (end_bit - bit)) - 1) << bit;
> *wordp |= mask;
> wordp++;
> bits_set = end_bit - bit;
This patch is whitespace damaged and fails to apply. I've fixed it
up as this is a trivial change. However, please fix the problem
before you submit more patches.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
r
easier to change the broken PMEM programming model assumptions than
it is to implement what you are suggesting. Or to do what Christoph
suggested and just use a wrapper around something like device
mapper to hand out chunks of unchanging, static pmem to
applications...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
e broken PMEM programming model assumptions than
it is to implement what you are suggesting. Or to do what Christoph
suggested and just use a wrapper around something like device
mapper to hand out chunks of unchanging, static pmem to
applications...
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
; fs/logfs/readwrite.c| 2298
> ---
> fs/logfs/segment.c | 961 ---
> fs/logfs/super.c| 653 --
Wasn't the lib/btree.c implementation introduced with and only used
by logfs? Should that go as well?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
readwrite.c| 2298
> ---
> fs/logfs/segment.c | 961 ---
> fs/logfs/super.c| 653 --
Wasn't the lib/btree.c implementation introduced with and only used
by logfs? Should that go as well?
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
pped and caller has CAP_LINUX_IMMUTABLE.
A flag like this /should/ make it possible to avoid fsync/msync() on
a file for existing filesystems, but it also means that such files
have significant management issues (hence the need for
CAP_LINUX_IMMUTABLE to cover it's use).
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
pped and caller has CAP_LINUX_IMMUTABLE.
A flag like this /should/ make it possible to avoid fsync/msync() on
a file for existing filesystems, but it also means that such files
have significant management issues (hence the need for
CAP_LINUX_IMMUTABLE to cover it's use).
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Fri, Aug 19, 2016 at 04:08:34PM +0100, Mel Gorman wrote:
> On Thu, Aug 18, 2016 at 05:11:11PM +1000, Dave Chinner wrote:
> > On Thu, Aug 18, 2016 at 01:45:17AM +0100, Mel Gorman wrote:
> > > On Wed, Aug 17, 2016 at 04:49:07PM +0100, Mel Gorman wrote:
> > > >
On Fri, Aug 19, 2016 at 04:08:34PM +0100, Mel Gorman wrote:
> On Thu, Aug 18, 2016 at 05:11:11PM +1000, Dave Chinner wrote:
> > On Thu, Aug 18, 2016 at 01:45:17AM +0100, Mel Gorman wrote:
> > > On Wed, Aug 17, 2016 at 04:49:07PM +0100, Mel Gorman wrote:
> > > >
in the deferred pending work item
Dave Chinner (1):
xfs: fix superblock inprogress check
fs/iomap.c | 5 -
fs/xfs/libxfs/xfs_alloc.c | 2 ++
fs/xfs/libxfs/xfs_btree.c | 14 +-
fs/xfs/libxfs/xfs_defer.c | 17 -
fs/xfs/libxfs/xfs_defer.h | 2
in the deferred pending work item
Dave Chinner (1):
xfs: fix superblock inprogress check
fs/iomap.c | 5 -
fs/xfs/libxfs/xfs_alloc.c | 2 ++
fs/xfs/libxfs/xfs_btree.c | 14 +-
fs/xfs/libxfs/xfs_defer.c | 17 -
fs/xfs/libxfs/xfs_defer.h | 2
equires us to know the size of the hole. This
>The current XFS code in the v4.8 tree tells me the size of the hole, and I
>think we need to keep this functionality.
IOMAP_HOLE extents. It's a requirement of the iomap infrastructure
that the filesystem reports hole extents in full for the range being
mapped.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
equires us to know the size of the hole. This
>The current XFS code in the v4.8 tree tells me the size of the hole, and I
>think we need to keep this functionality.
IOMAP_HOLE extents. It's a requirement of the iomap infrastructure
that the filesystem reports hole extents in full for the range being
mapped.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Fri, Aug 26, 2016 at 10:59:28AM +0200, Artem Savkov wrote:
> On Fri, Aug 26, 2016 at 08:42:15AM +1000, Dave Chinner wrote:
> > So when I look at the fix, and see that it doesn't reproduce on my
> > systems, it's clear that it's either not yet fully understood or
> > hasn't
On Fri, Aug 26, 2016 at 10:59:28AM +0200, Artem Savkov wrote:
> On Fri, Aug 26, 2016 at 08:42:15AM +1000, Dave Chinner wrote:
> > So when I look at the fix, and see that it doesn't reproduce on my
> > systems, it's clear that it's either not yet fully understood or
> > hasn't
On Thu, Aug 25, 2016 at 10:21:09AM +0200, Artem Savkov wrote:
> On Thu, Aug 25, 2016 at 10:24:08AM +1000, Dave Chinner wrote:
> > On Wed, Aug 24, 2016 at 10:08:33AM +0200, Artem Savkov wrote:
> > > On Wed, Aug 24, 2016 at 11:55:51AM +1000, Dave Chinner wrote:
> > > >
On Thu, Aug 25, 2016 at 10:21:09AM +0200, Artem Savkov wrote:
> On Thu, Aug 25, 2016 at 10:24:08AM +1000, Dave Chinner wrote:
> > On Wed, Aug 24, 2016 at 10:08:33AM +0200, Artem Savkov wrote:
> > > On Wed, Aug 24, 2016 at 11:55:51AM +1000, Dave Chinner wrote:
> > > >
On Wed, Aug 24, 2016 at 10:08:33AM +0200, Artem Savkov wrote:
> On Wed, Aug 24, 2016 at 11:55:51AM +1000, Dave Chinner wrote:
> > On Tue, Aug 23, 2016 at 05:54:13PM +0200, Artem Savkov wrote:
> > > Commit "xfs: only return -errno or success from attr ->p
On Wed, Aug 24, 2016 at 10:08:33AM +0200, Artem Savkov wrote:
> On Wed, Aug 24, 2016 at 11:55:51AM +1000, Dave Chinner wrote:
> > On Tue, Aug 23, 2016 at 05:54:13PM +0200, Artem Savkov wrote:
> > > Commit "xfs: only return -errno or success from attr ->p
ount + prefix_len + namelen + 1;
> if (arraytop > context->firstu) {
> context->count = -1;/* insufficient space */
> + context->seen_enough = 1;
> return 0;
> }
> offset = (char *)context->alist + context->count;
Looks sane, though I don't know how to test it yet
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
n + 1;
> if (arraytop > context->firstu) {
> context->count = -1;/* insufficient space */
> + context->seen_enough = 1;
> return 0;
> }
> offset = (char *)context->alist + context->count;
Looks sane, though I don't know how to test it yet
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Aug 22, 2016 at 07:18:26AM +0200, Willy Tarreau wrote:
> Hi Dave,
>
> On Mon, Aug 22, 2016 at 02:21:08PM +1000, Dave Chinner wrote:
> > > - if (error || !bp) {
> > > + if (error == -EAGAIN) {
> >
> > Wrong. Errors changed sign in XFS in 3.17.
>
On Mon, Aug 22, 2016 at 07:18:26AM +0200, Willy Tarreau wrote:
> Hi Dave,
>
> On Mon, Aug 22, 2016 at 02:21:08PM +1000, Dave Chinner wrote:
> > > - if (error || !bp) {
> > > + if (error == -EAGAIN) {
> >
> > Wrong. Errors changed sign in XFS in 3.17.
>
On Sun, Aug 21, 2016 at 05:30:20PM +0200, Willy Tarreau wrote:
> From: Dave Chinner <dchin...@redhat.com>
>
> commit b1438f477934f5a4d5a44df26f3079a7575d5946 upstream.
>
> When a failure due to an inode buffer occurs, the error handling
> fails to abort the inode write
On Sun, Aug 21, 2016 at 05:30:20PM +0200, Willy Tarreau wrote:
> From: Dave Chinner
>
> commit b1438f477934f5a4d5a44df26f3079a7575d5946 upstream.
>
> When a failure due to an inode buffer occurs, the error handling
> fails to abort the inode writeback correctly. This can res
is really hot...
I think the underlying principle here is that the faster the backing
device, the less we should cache and buffer the device in the OS. I
suspect a good initial approximation of "stickiness" for the page
cache would the speed of writeback as measured by the BDI underlying
the mapping
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
is really hot...
I think the underlying principle here is that the faster the backing
device, the less we should cache and buffer the device in the OS. I
suspect a good initial approximation of "stickiness" for the page
cache would the speed of writeback as measured by the BDI underlying
the mapping
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
rom the AGFL
Dave Chinner (4):
xfs: don't invalidate whole file on DAX read/write
iomap: fiemap should honor the FIEMAP_FLAG_SYNC flag
iomap: prepare iomap_fiemap for attribute mappings
Merge branch 'iomap-fixes-4.8-rc3' into for-next
fs/iomap.c |
rom the AGFL
Dave Chinner (4):
xfs: don't invalidate whole file on DAX read/write
iomap: fiemap should honor the FIEMAP_FLAG_SYNC flag
iomap: prepare iomap_fiemap for attribute mappings
Merge branch 'iomap-fixes-4.8-rc3' into for-next
fs/iomap.c |
On Thu, Aug 18, 2016 at 10:55:01AM -0700, Linus Torvalds wrote:
> On Thu, Aug 18, 2016 at 6:24 AM, Mel Gorman <mgor...@techsingularity.net>
> wrote:
> > On Thu, Aug 18, 2016 at 05:11:11PM +1000, Dave Chinner wrote:
> >> FWIW, I just remembered about /pr
On Thu, Aug 18, 2016 at 10:55:01AM -0700, Linus Torvalds wrote:
> On Thu, Aug 18, 2016 at 6:24 AM, Mel Gorman
> wrote:
> > On Thu, Aug 18, 2016 at 05:11:11PM +1000, Dave Chinner wrote:
> >> FWIW, I just remembered about /proc/sys/vm/zone_reclaim_mode.
> >>
>
he). Can use non-atomic bitops now (and
> - * we obviously don't have to worry about waking up a process
> - * waiting on the page lock, because there are no references.
> - */
> - __ClearPageLocked(page);
> + list_add(>lru, _pages);
> + if (ret == SWAP_LZFREE)
> + count_vm_event(PGLAZYFREED);
> + continue;
> +
> free_it:
> if (ret == SWAP_LZFREE)
> count_vm_event(PGLAZYFREED);
> @@ -1251,6 +1320,7 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page), page);
> }
>
> + remove_mapping_list(_pages, _pages, _pages);
> mem_cgroup_uncharge_list(_pages);
> try_to_unmap_flush();
> free_hot_cold_page_list(_pages, true);
>
--
Dave Chinner
da...@fromorbit.com
he). Can use non-atomic bitops now (and
> - * we obviously don't have to worry about waking up a process
> - * waiting on the page lock, because there are no references.
> - */
> - __ClearPageLocked(page);
> + list_add(>lru, _pages);
> + if (ret == SWAP_LZFREE)
> + count_vm_event(PGLAZYFREED);
> + continue;
> +
> free_it:
> if (ret == SWAP_LZFREE)
> count_vm_event(PGLAZYFREED);
> @@ -1251,6 +1320,7 @@ static unsigned long shrink_page_list(struct list_head
> *page_list,
> VM_BUG_ON_PAGE(PageLRU(page) || PageUnevictable(page), page);
> }
>
> + remove_mapping_list(_pages, _pages, _pages);
> mem_cgroup_uncharge_list(_pages);
> try_to_unmap_flush();
> free_hot_cold_page_list(_pages, true);
>
--
Dave Chinner
da...@fromorbit.com
xpensive
> exiting and reentery of the guest. I have a vague recollection that a
> spinning vcpu exits the guest but I did not confirm that.
I don't think anything like that has been implemented in the pv
spinlocks yet. They just spin right now - it's the same lock
implementation as the host. Also, Context switch rates measured on
the host are not significantly higher than what is measured in the
guest, so there doesn't appear to be any extra scheduling on the
host side occurring.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
xpensive
> exiting and reentery of the guest. I have a vague recollection that a
> spinning vcpu exits the guest but I did not confirm that.
I don't think anything like that has been implemented in the pv
spinlocks yet. They just spin right now - it's the same lock
implementation as the host. Also, Context switch rates measured on
the host are not significantly higher than what is measured in the
guest, so there doesn't appear to be any extra scheduling on the
host side occurring.
Cheers,
Dave.
--
Dave Chinner
da...@fromorbit.com
On Tue, Aug 16, 2016 at 08:45:02PM +0100, Ben Hutchings wrote:
> On Sun, 2016-08-14 at 09:36 +1000, Dave Chinner wrote:
> > On Sat, Aug 13, 2016 at 06:42:51PM +0100, Ben Hutchings wrote:
> > >
> > > 3.16.37-rc1 review patch. If anyone has any objections
On Tue, Aug 16, 2016 at 08:45:02PM +0100, Ben Hutchings wrote:
> On Sun, 2016-08-14 at 09:36 +1000, Dave Chinner wrote:
> > On Sat, Aug 13, 2016 at 06:42:51PM +0100, Ben Hutchings wrote:
> > >
> > > 3.16.37-rc1 review patch. If anyone has any objections
gt; that then doesn't consistently give 16 cores to the virtual machine,
> you'll get no end of hiccups.
I learnt that lesson 6-7 years ago when I first started doing
baseline benchmarking to compare bare metal to virtualised IO
performance.
-Dave.
--
Dave Chinner
da...@fromorbit.com
gt; that then doesn't consistently give 16 cores to the virtual machine,
> you'll get no end of hiccups.
I learnt that lesson 6-7 years ago when I first started doing
baseline benchmarking to compare bare metal to virtualised IO
performance.
-Dave.
--
Dave Chinner
da...@fromorbit.com
... ooh.
>
> Wait, I take that back.
>
> We actually have some very recent changes that I didn't even think
> about that went into this very merge window.
> Mel? The issue is that Dave Chinner is seeing some nasty spinlock
> contention on "mapping->tree_loc
ack.
>
> We actually have some very recent changes that I didn't even think
> about that went into this very merge window.
> Mel? The issue is that Dave Chinner is seeing some nasty spinlock
> contention on "mapping->tree_lock":
>
> > 31.18% [k
On Mon, Aug 15, 2016 at 04:20:55PM -0700, Linus Torvalds wrote:
> On Mon, Aug 15, 2016 at 3:42 PM, Dave Chinner <da...@fromorbit.com> wrote:
> >
> > 31.18% [kernel] [k] __pv_queued_spin_lock_slowpath
> >9.90% [kernel] [k] copy_user_generic_string
On Mon, Aug 15, 2016 at 04:20:55PM -0700, Linus Torvalds wrote:
> On Mon, Aug 15, 2016 at 3:42 PM, Dave Chinner wrote:
> >
> > 31.18% [kernel] [k] __pv_queued_spin_lock_slowpath
> >9.90% [kernel] [k] copy_user_generic_string
>
dirty
-Dave.
--
Dave Chinner
da...@fromorbit.com
dirty
-Dave.
--
Dave Chinner
da...@fromorbit.com
On Mon, Aug 15, 2016 at 04:01:00PM -0700, Linus Torvalds wrote:
> On Mon, Aug 15, 2016 at 3:22 PM, Dave Chinner <da...@fromorbit.com> wrote:
> >
> > Right, but that does not make the profile data useless,
>
> Yes it does. Because it basically hides everything that happe
On Mon, Aug 15, 2016 at 04:01:00PM -0700, Linus Torvalds wrote:
> On Mon, Aug 15, 2016 at 3:22 PM, Dave Chinner wrote:
> >
> > Right, but that does not make the profile data useless,
>
> Yes it does. Because it basically hides everything that happens inside
> the lo
On Mon, Aug 15, 2016 at 10:22:43AM -0700, Huang, Ying wrote:
> Hi, Chinner,
>
> Dave Chinner <da...@fromorbit.com> writes:
>
> > On Wed, Aug 10, 2016 at 06:00:24PM -0700, Linus Torvalds wrote:
> >> On Wed, Aug 10, 2016 at 5:33 PM, Huang, Ying <ying.hu...@
On Mon, Aug 15, 2016 at 10:22:43AM -0700, Huang, Ying wrote:
> Hi, Chinner,
>
> Dave Chinner writes:
>
> > On Wed, Aug 10, 2016 at 06:00:24PM -0700, Linus Torvalds wrote:
> >> On Wed, Aug 10, 2016 at 5:33 PM, Huang, Ying wrote:
> >> >
> >> >
On Tue, Aug 16, 2016 at 08:22:11AM +1000, Dave Chinner wrote:
> On Sun, Aug 14, 2016 at 10:12:20PM -0700, Linus Torvalds wrote:
> > On Aug 14, 2016 10:00 PM, "Dave Chinner" <da...@fromorbit.com> wrote:
> > >
> > > > What does it say if you annotate t
On Tue, Aug 16, 2016 at 08:22:11AM +1000, Dave Chinner wrote:
> On Sun, Aug 14, 2016 at 10:12:20PM -0700, Linus Torvalds wrote:
> > On Aug 14, 2016 10:00 PM, "Dave Chinner" wrote:
> > >
> > > > What does it say if you annotate that _r
On Sun, Aug 14, 2016 at 10:12:20PM -0700, Linus Torvalds wrote:
> On Aug 14, 2016 10:00 PM, "Dave Chinner" <da...@fromorbit.com> wrote:
> >
> > > What does it say if you annotate that _raw_spin_unlock_irqrestore()
> function?
> >
> >
On Sun, Aug 14, 2016 at 10:12:20PM -0700, Linus Torvalds wrote:
> On Aug 14, 2016 10:00 PM, "Dave Chinner" wrote:
> >
> > > What does it say if you annotate that _raw_spin_unlock_irqrestore()
> function?
> >
> >¿
&
t.xfs_vn_update_time.touch_atime.generic_file_read_iter.xfs_file_buffered_aio_read.xfs_file_read_iter.__vfs_read.vfs_read.SyS_read
Significant increase in blocking delays in the journal during atime
updates. There's nothing in Christoph's tree that would affect that
behaviour. This smells like either a mount option change or
individual tests not being 100% isolated and the previous test run
is affecting this one?
-Dave.
--
Dave Chinner
da...@fromorbit.com
t.xfs_vn_update_time.touch_atime.generic_file_read_iter.xfs_file_buffered_aio_read.xfs_file_read_iter.__vfs_read.vfs_read.SyS_read
Significant increase in blocking delays in the journal during atime
updates. There's nothing in Christoph's tree that would affect that
behaviour. This smells like either a mount option change or
individual tests not being 100% isolated and the previous test run
is affecting this one?
-Dave.
--
Dave Chinner
da...@fromorbit.com
On Sun, Aug 14, 2016 at 07:53:40PM -0700, Linus Torvalds wrote:
> On Sun, Aug 14, 2016 at 7:28 PM, Dave Chinner <da...@fromorbit.com> wrote:
> >>
> >> Maybe your symbol table came from a old kernel, and functions moved
> >> around enough that the profile attrib
On Sun, Aug 14, 2016 at 07:53:40PM -0700, Linus Torvalds wrote:
> On Sun, Aug 14, 2016 at 7:28 PM, Dave Chinner wrote:
> >>
> >> Maybe your symbol table came from a old kernel, and functions moved
> >> around enough that the profile attributions ended up bogus.
&
On Sun, Aug 14, 2016 at 06:37:33PM -0700, Linus Torvalds wrote:
> On Sun, Aug 14, 2016 at 5:48 PM, Dave Chinner <da...@fromorbit.com> wrote:
> >>
> >> Does this attached patch help your contention numbers?
> >
> > No. If anything, it makes it worse. Witho
On Sun, Aug 14, 2016 at 06:37:33PM -0700, Linus Torvalds wrote:
> On Sun, Aug 14, 2016 at 5:48 PM, Dave Chinner wrote:
> >>
> >> Does this attached patch help your contention numbers?
> >
> > No. If anything, it makes it worse. Without the
On Fri, Aug 12, 2016 at 11:03:33AM -0700, Linus Torvalds wrote:
> On Thu, Aug 11, 2016 at 8:56 PM, Dave Chinner <da...@fromorbit.com> wrote:
> > On Thu, Aug 11, 2016 at 07:27:52PM -0700, Linus Torvalds wrote:
> >>
> >> I don't recall having ever seen the
On Fri, Aug 12, 2016 at 11:03:33AM -0700, Linus Torvalds wrote:
> On Thu, Aug 11, 2016 at 8:56 PM, Dave Chinner wrote:
> > On Thu, Aug 11, 2016 at 07:27:52PM -0700, Linus Torvalds wrote:
> >>
> >> I don't recall having ever seen the mapping tree_lock as a contention
1101 - 1200 of 3916 matches
Mail list logo
