Hi,
On 2021-02-03 15:58:33 -0700, Jens Axboe wrote:
> On 2/3/21 3:06 PM, Greg Kroah-Hartman wrote:
> > On Wed, Feb 03, 2021 at 01:28:26PM -0800, Andres Freund wrote:
> >> On 2021-02-03 14:03:09 +0100, Greg Kroah-Hartman wrote:
> >>>> On v5.4.43-101-gbba91cdba612
c: sta...@vger.kernel.org # v5.6
Reported-by: Bijan Mottahedeh
Signed-off-by: Jens Axboe
I suspect it just wasn't aimed at 5.4, and that's that, but I'm not
sure. In which case presumably reverting
bba91cdba612fbce4f8575c5d94d2b146fb83ea3 would be the right fix, not
backporting 4503b7676a2e0abe69c2f2c0d8b03aec53f2f048 et al.
Greetings,
Andres Freund
e overhead by
not first trying, then retrying from async context. We can go straight
to async punt instead.
Signed-off-by: Jens Axboe
which isn't in stable/linux-5.4.y
Greetings,
Andres Freund
Hi,
On 2021-01-24 01:59:05 +, Al Viro wrote:
> On Sat, Jan 23, 2021 at 03:50:55PM -0800, Andres Freund wrote:
>
> > As there's only a shared lock, seems like both would end up with the
> > same ctx->pos and end up updating f_pos to the same offset (assuming the
> >
Hi,
On 2021-01-23 15:50:55 -0800, Andres Freund wrote:
> It's also not clear to me that right now you'd necessarily get correct
> results if multiple IORING_OP_GETDENTS64 for the same fd get processed
> in different workers. Looking at iterate_dir(), it looks to me that the
> lo
h would end up with the
same ctx->pos and end up updating f_pos to the same offset (assuming the
same count).
Am I missing something?
Greetings,
Andres Freund
This was missed in 021a24460dc2. Leads to the numeric value of
QUEUE_FLAG_NOWAIT (i.e. 29) showing up in
/sys/kernel/debug/block/*/state.
Fixes: 021a24460dc28e7412aecfae89f60e1847e685c0
Cc: Konstantin Khlebnikov
Cc: Mike Snitzer
Cc: Christoph Hellwig
Cc: Jens Axboe
Signed-off-by: Andres
quirks indicating
slow FUA for those devices? But I'll leave that for later...
Greetings,
Andres Freund
The following commit has been merged into the thermal/next branch of thermal:
Commit-ID: e78acf7efebff9184ad4add02b62a1f486a8cde8
Gitweb:
https://git.kernel.org/pub/scm/linux/kernel/git/thermal/linux.git//e78acf7efebff9184ad4add02b62a1f486a8cde8
Author:Andres Freund
Hi,
On 2020-11-16 10:28:04 +0100, Daniel Lezcano wrote:
> On 13/11/2020 21:49, Andres Freund wrote:
> > I noticed that I couldn't read the PCH temperature on my workstation
> > (C620 series chipset, w/ 2x Xeon Gold 5215 CPUs) directly, but had to go
> > through IPMI. Look
Hi,
On 2020-11-12 12:34:08 +0100, Daniel Lezcano wrote:
> It does no longer apply, is it possible to do a respin ?
Yep, sent.
Thanks,
- Andres
/20200115184415.1726953-1-and...@anarazel.de/
Signed-off-by: Andres Freund
---
drivers/thermal/intel/intel_pch_thermal.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/thermal/intel/intel_pch_thermal.c
b/drivers/thermal/intel/intel_pch_thermal.c
index 3b813ebb6ca1
Hi,
On 2020-01-16 11:41:34 -0800, Srinivas Pandruvada wrote:
> On Thu, 2020-01-16 at 10:42 -0800, Andres Freund wrote:
> > Hi,
> >
> > On 2020-01-16 05:53:13 -0800, Srinivas Pandruvada wrote:
> > > On Wed, 2020-01-15 at 10:44 -0800, Andres Freund wrote:
> >
ue. Which is checked
by io_prep_async_work(), adding the current mm to req. On the wq side
io_wq_switch_mm() uses that mm when executing the queue entry.
Greetings,
Andres Freund
nly use case for wanting the
submitting mm to be the relevant one, not the creating one. It seems far
more dangerous to use the creating mm than the submitting mm. Makes
things like passing a uring fd with a few pre-opened files to another
process impossible.
Greetings,
Andres Freund
Hi,
On 2020-06-05 16:56:44 -0600, Jens Axboe wrote:
> On 6/5/20 4:54 PM, Andres Freund wrote:
> > On 2020-06-05 16:49:24 -0600, Jens Axboe wrote:
> >> Yes that's expected, if we have to fallback to ->readpage(), then it'll
> >> go to a worker. read-ahead i
the normal read, then wait for it.
But I assume async would still work for files with POSIX_FADV_RANDOM
set, or not? Assuming the system wide setting isn't zero, of course.
Greetings,
Andres Freund
Hi,
On 2020-06-05 15:30:44 -0700, Andres Freund wrote:
> On 2020-06-05 15:21:34 -0600, Jens Axboe wrote:
> > >> I can reproduce this, and I see what it is. I'll send out a patch
> > >> soonish.
> > >
> > > Thinko, can you try with this on top?
&
uffered reads somehow don't quite seem to be performing that well
though, looking into it. Could be on the pg side too.
Greetings,
Andres Freund
Hi,
On 2020-06-05 13:20:28 -0700, Andres Freund wrote:
> I'll go and try to figure out why I don't see an oops...
Err, that probably was a typo on my end in the serial console
config. After fixing that, I did get the below.
If helpful I can try with debugging enabled or such.
[ 67.910
Hi,
On 2020-06-05 08:42:28 -0600, Jens Axboe wrote:
> Can you try with async-buffered.7? I've rebased it on a new mechanism,
> and doing something like what you describe above I haven't been able
> to trigger anything bad. I'd try your test case specifically, so do let
> know if it's something I
Hi,
On 2020-06-03 18:30:45 -0700, Andres Freund wrote:
> > I'll try and reproduce this, any chance you have a test case that can
> > be run so I don't have to write one from scratch? The more detailed
> > instructions the better.
>
> It shouldn't be too hard to wri
load the results are
*worse* than when using 5.7-rc7 io_uring. So perhaps request starvation
isn't the worst guess...
Greetings,
Andres Freund
Hi,
On 2019-07-26 09:12:00 -0400, Steven Rostedt wrote:
> On Thu, 25 Jul 2019 20:58:29 -0700
> Andres Freund wrote:
> >
> > Is just plain wrong, as:
> >
> > > - return pevent->events[idx];
> > > + return (all_events + idx);
>
335653b24784d6042be8e4aee114403
Author: Steven Rostedt
Date: 2012-04-06 00:47:56 +0200
perf: Have perf use the new libtraceevent.a library
seem to make the current API somewhat absurd, as evidenced by the
complexity in trace_find_next_event(). I mean even just removing that
function and changing the two callsites to simple for loops with
tep_get_events_count() & tep_get_event() ought to be a lot better.
Greetings,
Andres Freund
sure nothing gets lost.
In case this is something that won't be fixed, it seems appropriate to
add a section to the man pages (hence CCing linux man-pages list)
Greetings,
Andres Freund
to make sure nothing gets lost.
In case this is something that won't be fixed, it seems appropriate to
add a section to the man pages (hence CCing linux man-pages list)
Greetings,
Andres Freund
On 2018-04-23 14:51:50 -0700, Matthew Wilcox wrote:
> How does this look?
>
> @@ -111,27 +111,22 @@ EXPORT_SYMBOL(errseq_set);
> * errseq_sample() - Grab current errseq_t value.
> * @eseq: Pointer to errseq_t to be sampled.
> *
> - * This function allows callers to sample an errseq_t value,
On 2018-04-23 14:51:50 -0700, Matthew Wilcox wrote:
> How does this look?
>
> @@ -111,27 +111,22 @@ EXPORT_SYMBOL(errseq_set);
> * errseq_sample() - Grab current errseq_t value.
> * @eseq: Pointer to errseq_t to be sampled.
> *
> - * This function allows callers to sample an errseq_t value,
On 2018-04-23 14:43:48 -0700, Matthew Wilcox wrote:
> On Mon, Apr 23, 2018 at 01:57:30PM -0700, Andres Freund wrote:
> > I've never really looked at this code in any depth before, but won't
> > this potentially lead to the same error being reported on multiple FDs?
> > Imagine
On 2018-04-23 14:43:48 -0700, Matthew Wilcox wrote:
> On Mon, Apr 23, 2018 at 01:57:30PM -0700, Andres Freund wrote:
> > I've never really looked at this code in any depth before, but won't
> > this potentially lead to the same error being reported on multiple FDs?
> > Imagine
ile_check_and_advance_wb_err() will return an error that's always
unlike 0 in that case, and thus the error will returned on both fds?
I'm personally perfectly fine with that, but it's not necessarily what's
described as desired in your email?.
Greetings,
Andres Freund
rr() will return an error that's always
unlike 0 in that case, and thus the error will returned on both fds?
I'm personally perfectly fine with that, but it's not necessarily what's
described as desired in your email?.
Greetings,
Andres Freund
On 2018-01-03 13:57:25 +0100, Willy Tarreau wrote:
> On Tue, Jan 02, 2018 at 01:09:13PM -0800, Linus Torvalds wrote:
> > On Tue, Jan 2, 2018 at 12:28 PM, Andres Freund <and...@anarazel.de> wrote:
> > >
> > > I thought it'd be interesting to run a short bench
On 2018-01-03 13:57:25 +0100, Willy Tarreau wrote:
> On Tue, Jan 02, 2018 at 01:09:13PM -0800, Linus Torvalds wrote:
> > On Tue, Jan 2, 2018 at 12:28 PM, Andres Freund wrote:
> > >
> > > I thought it'd be interesting to run a short benchmark to be able to
> > >
On 2017-12-31 14:57:51 -0800, Linus Torvalds wrote:
> With all the x86 pti work coming in late in the rc like this, I'm by
> now almost guaranteed to do an rc8 this release, not because there are
> any known problems, but simply because of the timing of the patches.
>
> Go forth and test,
I
On 2017-12-31 14:57:51 -0800, Linus Torvalds wrote:
> With all the x86 pti work coming in late in the rc like this, I'm by
> now almost guaranteed to do an rc8 this release, not because there are
> any known problems, but simply because of the timing of the patches.
>
> Go forth and test,
I
On 2017-07-12 17:40:45 -0500, Josh Poimboeuf wrote:
> On Wed, Jul 12, 2017 at 03:36:05PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2017-07-12 17:32:25 -0500, Josh Poimboeuf wrote:
> > > If you want perf to be able to use ORC instead of DWARF for use
On 2017-07-12 17:40:45 -0500, Josh Poimboeuf wrote:
> On Wed, Jul 12, 2017 at 03:36:05PM -0700, Andres Freund wrote:
> > Hi,
> >
> > On 2017-07-12 17:32:25 -0500, Josh Poimboeuf wrote:
> > > If you want perf to be able to use ORC instead of DWARF for use
ight, that's what I was hoping for.
> And I think it should be possible to convert DWARF to ORC, assuming the
> DWARF data is trusted. We could probably add an objtool subcommand for
> that.
That'd be pretty helpful.
Greetings,
Andres Freund
ight, that's what I was hoping for.
> And I think it should be possible to convert DWARF to ORC, assuming the
> DWARF data is trusted. We could probably add an objtool subcommand for
> that.
That'd be pretty helpful.
Greetings,
Andres Freund
Hi,
On 2017-07-11 10:33:37 -0500, Josh Poimboeuf wrote:
> The simpler debuginfo format also enables the unwinder to be much faster
> than DWARF, which is important for perf and lockdep.
Is this going to be usable for userland call-graphs as well? If one
converts dwarf to that, I mean? Because
Hi,
On 2017-07-11 10:33:37 -0500, Josh Poimboeuf wrote:
> The simpler debuginfo format also enables the unwinder to be much faster
> than DWARF, which is important for perf and lockdep.
Is this going to be usable for userland call-graphs as well? If one
converts dwarf to that, I mean? Because
h merged VMAs its
relatively harmless, since it'll presumably mostly be memory allocations
and such, where this wont matter.
Greetings,
Andres Freund
h merged VMAs its
relatively harmless, since it'll presumably mostly be memory allocations
and such, where this wont matter.
Greetings,
Andres Freund
flags |= MAP_EXECUTABLE;
> - if (vma->vm_flags & VM_LOCKED)
> - flags |= MAP_LOCKED;
> - if (vma->vm_flags & VM_HUGETLB)
> - flags |= MAP_HUGETLB;
> -
> goto got_name;
&
flags |= MAP_EXECUTABLE;
> - if (vma->vm_flags & VM_LOCKED)
> - flags |= MAP_LOCKED;
> - if (vma->vm_flags & VM_HUGETLB)
> - flags |= MAP_HUGETLB;
> -
> goto got_nam
On 2017-01-26 14:26:12 -0800, Stephane Eranian wrote:
> On Thu, Jan 26, 2017 at 2:19 PM, Peter Zijlstra <pet...@infradead.org> wrote:
> > On Thu, Jan 26, 2017 at 01:00:52PM -0800, Andres Freund wrote:
> >> The problem is that (quoted below) without that hack the subsequen
On 2017-01-26 14:26:12 -0800, Stephane Eranian wrote:
> On Thu, Jan 26, 2017 at 2:19 PM, Peter Zijlstra wrote:
> > On Thu, Jan 26, 2017 at 01:00:52PM -0800, Andres Freund wrote:
> >> The problem is that (quoted below) without that hack the subsequent
> >> mmaps just exp
Hi,
On 2017-01-26 13:34:35 -0800, Stephane Eranian wrote:
> On Thu, Jan 26, 2017 at 1:22 PM, Andres Freund <and...@anarazel.de> wrote:
> >
> > On 2017-01-26 13:17:56 -0800, Stephane Eranian wrote:
> > > > Nope, not yet. I didn't want to submit an implementati
Hi,
On 2017-01-26 13:34:35 -0800, Stephane Eranian wrote:
> On Thu, Jan 26, 2017 at 1:22 PM, Andres Freund wrote:
> >
> > On 2017-01-26 13:17:56 -0800, Stephane Eranian wrote:
> > > > Nope, not yet. I didn't want to submit an implementation that has the
> > >
On 2017-01-26 13:17:56 -0800, Stephane Eranian wrote:
> > Nope, not yet. I didn't want to submit an implementation that has the
> > ugly hack of mmap()ing /dev/zero pages to prevent VMA merging ;). But
> > once that's resolved I plan to push it upstream (they indicated
> > interest). As long as
On 2017-01-26 13:17:56 -0800, Stephane Eranian wrote:
> > Nope, not yet. I didn't want to submit an implementation that has the
> > ugly hack of mmap()ing /dev/zero pages to prevent VMA merging ;). But
> > once that's resolved I plan to push it upstream (they indicated
> > interest). As long as
Hi Stephane,
On 2017-01-26 12:32:02 -0800, Stephane Eranian wrote:
> On Fri, Dec 9, 2016 at 9:02 PM, Andres Freund <and...@anarazel.de> wrote:
> > Hi,
> >
> > While working on optionally jit-compiling parts of postgres using llvm
> > (MCJIT currently, but Orc
Hi Stephane,
On 2017-01-26 12:32:02 -0800, Stephane Eranian wrote:
> On Fri, Dec 9, 2016 at 9:02 PM, Andres Freund wrote:
> > Hi,
> >
> > While working on optionally jit-compiling parts of postgres using llvm
> > (MCJIT currently, but Orc would have the same issue afa
Hi,
On 2016-12-12 10:28:13 +0100, Peter Zijlstra wrote:
> On Mon, Dec 12, 2016 at 01:01:48AM -0800, Andres Freund wrote:
> >
> >
> > On December 12, 2016 12:49:03 AM PST, Peter Zijlstra <pet...@infradead.org>
> > wrote:
> > >On Fri, Dec 09, 201
Hi,
On 2016-12-12 10:28:13 +0100, Peter Zijlstra wrote:
> On Mon, Dec 12, 2016 at 01:01:48AM -0800, Andres Freund wrote:
> >
> >
> > On December 12, 2016 12:49:03 AM PST, Peter Zijlstra
> > wrote:
> > >On Fri, Dec 09, 2016 at 09:02:18PM -0800, Andres
On December 12, 2016 12:49:03 AM PST, Peter Zijlstra <pet...@infradead.org>
wrote:
>On Fri, Dec 09, 2016 at 09:02:18PM -0800, Andres Freund wrote:
>> Am I doing something wrong, or is there a bug here?
>
>Expected behaviour afaict
So I need to prevent vma merging to
On December 12, 2016 12:49:03 AM PST, Peter Zijlstra
wrote:
>On Fri, Dec 09, 2016 at 09:02:18PM -0800, Andres Freund wrote:
>> Am I doing something wrong, or is there a bug here?
>
>Expected behaviour afaict
So I need to prevent vma merging to use perf jit support? That see
Hi,
While working on optionally jit-compiling parts of postgres using llvm
(MCJIT currently, but Orc would have the same issue afaics), I'm trying
to use perf jit support to make profiling of those JITed parts easier.
Turns out the current jit support in perf doesn't work that well for
LLVM -
Hi,
While working on optionally jit-compiling parts of postgres using llvm
(MCJIT currently, but Orc would have the same issue afaics), I'm trying
to use perf jit support to make profiling of those JITed parts easier.
Turns out the current jit support in perf doesn't work that well for
LLVM -
Hi,
On 2016-05-02 16:24:08 -0700, Greg KH wrote:
> On Mon, May 02, 2016 at 03:25:25PM -0700, Andres Freund wrote:
> > On 2016-05-02 15:17:54 -0700, Greg KH wrote:
> > Sorry for that, I'd used git describe on the commit to determine which
> > branch it was contained in
Hi,
On 2016-05-02 16:24:08 -0700, Greg KH wrote:
> On Mon, May 02, 2016 at 03:25:25PM -0700, Andres Freund wrote:
> > On 2016-05-02 15:17:54 -0700, Greg KH wrote:
> > Sorry for that, I'd used git describe on the commit to determine which
> > branch it was contained in
Hi,
On 2016-05-02 15:17:54 -0700, Greg KH wrote:
> On Mon, Apr 18, 2016 at 07:25:22AM -0700, Andres Freund wrote:
> > Hi,
> >
> > Perhaps the patch quoted below should also go into stable? It'd be nice
> > to fix that regression for 4.4 and 4.5. It's been integra
Hi,
On 2016-05-02 15:17:54 -0700, Greg KH wrote:
> On Mon, Apr 18, 2016 at 07:25:22AM -0700, Andres Freund wrote:
> > Hi,
> >
> > Perhaps the patch quoted below should also go into stable? It'd be nice
> > to fix that regression for 4.4 and 4.5. It's been integra
Hi,
Perhaps the patch quoted below should also go into stable? It'd be nice
to fix that regression for 4.4 and 4.5. It's been integrated into 4.6
(909890355).
Regards,
Andres
On 2016-03-30 23:33:37 -0700, tip-bot for Andres Freund wrote:
> Commit-ID: 909890355507e92bdaf648e73870f6b5df606
Hi,
Perhaps the patch quoted below should also go into stable? It'd be nice
to fix that regression for 4.4 and 4.5. It's been integrated into 4.6
(909890355).
Regards,
Andres
On 2016-03-30 23:33:37 -0700, tip-bot for Andres Freund wrote:
> Commit-ID: 909890355507e92bdaf648e73870f6b5df606
Hi,
Perhaps this should also go into stable? It'd be nice to fix that
regression for 4.4 and 4.5.
Regards,
Andres
On 2016-03-30 23:33:37 -0700, tip-bot for Andres Freund wrote:
> Commit-ID: 909890355507e92bdaf648e73870f6b5df606da8
> Gitweb: http://git.kernel.o
Hi,
Perhaps this should also go into stable? It'd be nice to fix that
regression for 4.4 and 4.5.
Regards,
Andres
On 2016-03-30 23:33:37 -0700, tip-bot for Andres Freund wrote:
> Commit-ID: 909890355507e92bdaf648e73870f6b5df606da8
> Gitweb: http://git.kernel.o
Hi Johannes,
On 2016-04-04 13:13:35 -0400, Johannes Weiner wrote:
> this is a follow-up to http://www.spinics.net/lists/linux-mm/msg101739.html
> where Andres reported his database workingset being pushed out by the
> minimum size enforcement of the inactive file list - currently 50% of cache
> -
Hi Johannes,
On 2016-04-04 13:13:35 -0400, Johannes Weiner wrote:
> this is a follow-up to http://www.spinics.net/lists/linux-mm/msg101739.html
> where Andres reported his database workingset being pushed out by the
> minimum size enforcement of the inactive file list - currently 50% of cache
> -
Commit-ID: 909890355507e92bdaf648e73870f6b5df606da8
Gitweb: http://git.kernel.org/tip/909890355507e92bdaf648e73870f6b5df606da8
Author: Andres Freund <and...@anarazel.de>
AuthorDate: Wed, 30 Mar 2016 21:02:45 +0200
Committer: Arnaldo Carvalho de Melo <a...@redhat.com>
CommitD
Commit-ID: 909890355507e92bdaf648e73870f6b5df606da8
Gitweb: http://git.kernel.org/tip/909890355507e92bdaf648e73870f6b5df606da8
Author: Andres Freund
AuthorDate: Wed, 30 Mar 2016 21:02:45 +0200
Committer: Arnaldo Carvalho de Melo
CommitDate: Wed, 30 Mar 2016 18:08:39 -0300
perf hists
Hi!
On 2016-03-31 01:00:10 +0900, Namhyung Kim wrote:
> On Wed, Mar 30, 2016 at 04:19:26PM +0200, Andres Freund wrote:
> > On 2016-03-30 10:46:34 -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Mar 30, 2016 at 02:34:18PM +0200, Andres Freund es
Hi!
On 2016-03-31 01:00:10 +0900, Namhyung Kim wrote:
> On Wed, Mar 30, 2016 at 04:19:26PM +0200, Andres Freund wrote:
> > On 2016-03-30 10:46:34 -0300, Arnaldo Carvalho de Melo wrote:
> > > Em Wed, Mar 30, 2016 at 02:34:18PM +0200, Andres Freund es
On 2016-03-30 10:46:34 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 30, 2016 at 02:34:18PM +0200, Andres Freund escreveu:
> > Hi,
> >
> > 4b3a3212233a - "perf hists browser: Support flat callchains" seems to
> > have broken callchain disp
On 2016-03-30 10:46:34 -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Mar 30, 2016 at 02:34:18PM +0200, Andres Freund escreveu:
> > Hi,
> >
> > 4b3a3212233a - "perf hists browser: Support flat callchains" seems to
> > have broken callchain disp
_unaligned
__memcpy_sse2_unaligned
as you can see after the aforementioned commit there's only one level of
callers reported.
--stdio output isn't affected.
I can provide an example perf.data file, but it apears to reproduce with
just about any profile here.
Greetings,
Andres Freund
_unaligned
__memcpy_sse2_unaligned
as you can see after the aforementioned commit there's only one level of
callers reported.
--stdio output isn't affected.
I can provide an example perf.data file, but it apears to reproduce with
just about any profile here.
Greetings,
Andres Freund
On 2016-02-17 16:17:44 -0500, Rik van Riel wrote:
> On Fri, 12 Feb 2016 20:35:53 +0100
> Andres Freund <and...@anarazel.de> wrote:
>
> > On 2016-02-12 13:46:53 +0100, Andres Freund wrote:
> > > I'm wondering why pages that are repeatedly written to, in u
On 2016-02-17 16:17:44 -0500, Rik van Riel wrote:
> On Fri, 12 Feb 2016 20:35:53 +0100
> Andres Freund wrote:
>
> > On 2016-02-12 13:46:53 +0100, Andres Freund wrote:
> > > I'm wondering why pages that are repeatedly written to, in units above
> > > the page size
Hi Johannes,
On 2016-02-12 15:24:05 -0500, Johannes Weiner wrote:
> I've updated the patch to work with cgroups.
Are tests of this patch, in contrast to the earlier version, necessary?
If so, what's this patch based upon? Because it doesn't seem to apply
cleanly to any tree I know about. Not
Hi Johannes,
On 2016-02-12 15:24:05 -0500, Johannes Weiner wrote:
> I've updated the patch to work with cgroups.
Are tests of this patch, in contrast to the earlier version, necessary?
If so, what's this patch based upon? Because it doesn't seem to apply
cleanly to any tree I know about. Not
On 2016-02-12 13:46:53 +0100, Andres Freund wrote:
> I'm wondering why pages that are repeatedly written to, in units above
> the page size, are promoted to the active list? I mean if there never
> are any reads or re-dirtying an already-dirty page, what's the benefit
> of moving th
ve file pages get deactivated, until more
* than half of the file pages are on the inactive list.
*
Would need updating with this patch.
Regards,
Andres Freund
moving that page onto the active list?
I imagine that high volumne streaming writes are generally pretty common
(non durability log-files!), and streaming over-writing sounds also
something a number of applications are doing.
Greetings,
Andres Freund
moving that page onto the active list?
I imagine that high volumne streaming writes are generally pretty common
(non durability log-files!), and streaming over-writing sounds also
something a number of applications are doing.
Greetings,
Andres Freund
ve file pages get deactivated, until more
* than half of the file pages are on the inactive list.
*
Would need updating with this patch.
Regards,
Andres Freund
On 2016-02-12 13:46:53 +0100, Andres Freund wrote:
> I'm wondering why pages that are repeatedly written to, in units above
> the page size, are promoted to the active list? I mean if there never
> are any reads or re-dirtying an already-dirty page, what's the benefit
> of moving th
Hi,
I'm working on fixing long IO stalls with postgres. After some
architectural changes fixing the worst issues, I noticed that indivdiual
processes/backends/connections still spend more time waiting than I'd
expect.
In an workload with the hot data set fitting into memory (2GB of
Hi,
I'm working on fixing long IO stalls with postgres. After some
architectural changes fixing the worst issues, I noticed that indivdiual
processes/backends/connections still spend more time waiting than I'd
expect.
In an workload with the hot data set fitting into memory (2GB of
On 2016-01-19 19:59:35 -0800, Linus Torvalds wrote:
> Are there other users outside of Solace? It would be good to get comments..
PostgreSQL is a potential user of async fdatasync, fsync,
sync_file_range and potentially readahead, write, read. First tests with
Dave's async fsync/fsync_range are
On 2016-01-12 12:11:28 +1100, Dave Chinner wrote:
> On Mon, Jan 11, 2016 at 05:07:23PM -0500, Benjamin LaHaise wrote:
> > Enable a fully asynchronous fsync and fdatasync operations in aio using
> > the aio thread queuing mechanism.
> >
> > Signed-off-by: Benjamin LaHaise
> > Signed-off-by:
On 2016-01-19 19:59:35 -0800, Linus Torvalds wrote:
> Are there other users outside of Solace? It would be good to get comments..
PostgreSQL is a potential user of async fdatasync, fsync,
sync_file_range and potentially readahead, write, read. First tests with
Dave's async fsync/fsync_range are
On 2016-01-12 12:11:28 +1100, Dave Chinner wrote:
> On Mon, Jan 11, 2016 at 05:07:23PM -0500, Benjamin LaHaise wrote:
> > Enable a fully asynchronous fsync and fdatasync operations in aio using
> > the aio thread queuing mechanism.
> >
> > Signed-off-by: Benjamin LaHaise
On 2015-10-29 12:54:22 +1100, Dave Chinner wrote:
> On Thu, Oct 29, 2015 at 12:23:12AM +0100, Andres Freund wrote:
> > The blocking/latency of the fsync doesn't actually matter at all *for
> > this callsite*. It's called from a dedicated background process - if
> > it's sl
On 2015-10-29 12:54:22 +1100, Dave Chinner wrote:
> On Thu, Oct 29, 2015 at 12:23:12AM +0100, Andres Freund wrote:
> > The blocking/latency of the fsync doesn't actually matter at all *for
> > this callsite*. It's called from a dedicated background process - if
> > it's sl
ood for
latency sensitive workloads tho.
At the moment using fdatasync() instead of fsync() is a considerable
performance advantage... If I understand the above proposal correctly,
it'd allow specifying ranges, is that right?
There'll be some concern about portability around this - issuing
sync_fil
want to do writeback from the syscall, right? i.e. you'd
> like to expire the inode behind the fd, and schedule background
> writeback to run on it immediately?
Yes, that's exactly what we want. Blocking if a process has done too
much writes is fine tho.
Greetings,
Andres Freund
--
To
ood for
latency sensitive workloads tho.
At the moment using fdatasync() instead of fsync() is a considerable
performance advantage... If I understand the above proposal correctly,
it'd allow specifying ranges, is that right?
There'll be some concern about portability around this - issuing
sync_fil
1 - 100 of 193 matches
Mail list logo
