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
void doing endless spins of resubmits.
Cc: 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
NOWAIT. That saves us some 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
&
s 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
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
dd an nvme 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. Loo
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
l.org/lkml/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 3b
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:
> > &g
m is true. 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
far from the only 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
gt; 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?
&
ulk buffered 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.
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 c
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
0
0.000.000.001.38 98.70
It's maybe also worth noting that in this workload 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);
>
nges in
commit aaf045f72335653b24784d6042be8e4aee114403
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
l scm information on the data level 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: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?
> &g
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
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 though
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 user sp
C data.
Right, 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 rig
other cases with merged VMAs its
relatively harmless, since it'll presumably mostly be memory allocations
and such, where this wont matter.
Greetings,
Andres Freund
t; - flags |= MAP_EXECUTABLE;
> - if (vma->vm_flags & VM_LOCKED)
> - flags |= MAP_LOCKED;
> - if (vma->vm_flags & VM_HUGETLB)
> - flags |= MAP_HUGETLB;
> -
> goto got_name
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 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 I
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
> > wrote:
> > >On Fri, Dec 09, 2016 at 09:02:18PM -0800, Andres
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 - but
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 containe
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 be
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: 909890355507e92bdaf648e7387
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.ker
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
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
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 display in
_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 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
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 very
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
active 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
ty page, what's the benefit
of 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
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
mmap(HUGE|ANNO
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 po
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: Benjam
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
> &g
to issue multiple
asynchronous fsyncs in this background process. Might not be good 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 th
ok() and the callbacks it calls..
> You don't 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 h
rspace. A new fadvise flags seems like a good way to do that -
POSIX_FADV_DONTNEED actually does non-integrity writeback, but also does
other things, so it's not suitable for us.
Greetings,
Andres Freund
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On 2015-07-09 04:45:38 +0200, Mike Galbraith wrote:
> On Wed, 2015-07-08 at 17:45 +0200, Andres Freund wrote:
> > Workload:
> >
> > postgresql (multi-process via shared memory SQL server) and benchmark
> > client (pgbench, multi threaded) running on the same serve
Hi,
while debugging a performance issue I noticed the following very odd
bit.
Kernel: 4.1.0-rc7-andres-00049-ge64f638
CPU: 2xE5520
Workload:
postgresql (multi-process via shared memory SQL server) and benchmark
client (pgbench, multi threaded) running on the same server. Connected
using unix so
Hi,
On 2012-09-17 13:15:14 +0200, Andres Freund wrote:
> On Monday, September 17, 2012 11:59:34 AM Jerome Glisse wrote:
> > On Mon, Sep 17, 2012 at 5:13 AM, Andres Freund wrote:
> > > On Monday, September 17, 2012 10:47:10 AM Jerome Glisse wrote:
> > >> On Sun, S
unmap_single_vma
unmap_vmas
exit_mmap
mmput.part.27
mmput
exit_mm
do_exit
d
On 2015-03-05 18:01:08 +0100, Vlastimil Babka wrote:
> On 03/05/2015 05:52 PM, Andres Freund wrote:
> > What exactly counts as "recent" in this context? Most of the bigger
> > installations where we found THP to be absolutely prohibitive (slowdowns
> > on the ord
bitive (slowdowns
on the order of a magnitude, huge latency spikes) unfortunately run
quite old kernels... I guess 3.11 does *not* count :/? That'd be a
bigger machine where I could relatively quickly reenable THP to check
whether it's still bad. I might be able to trigger it to be rebooted
onto a ne
ything else I can do?
Greetings,
Andres Freund
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
; >
> > In this case we do have a lock (sort of), so lockless_dereference() is
> > quite misleading.
> >
>
> Hi Eric,
>
> Thanks for looking at this patch.
>
> I've been scratching my head since morning trying to find out what was
> so obviously wro
entioned was because one of the machines I could
reboot used bonding. As seen above it's independant of that.
> btw, could i ask you to try attached patch?
I'll try later. Thought it made sense to give you the above reproducer
alone.
Greetings,
Andres Freund
--
To unsubscribe
On 2014-09-10 01:48:06 +0200, Andres Freund wrote:
> On 2014-09-09 15:43:55 -0700, Cong Wang wrote:
> > On Mon, Sep 8, 2014 at 2:25 PM, Andres Freund wrote:
> > > Hi,
> > >
> > > (don't have netdev archived, thus answering here, sorry)
> > >
>
On 2014-09-09 15:43:55 -0700, Cong Wang wrote:
> On Mon, Sep 8, 2014 at 2:25 PM, Andres Freund wrote:
> > Hi,
> >
> > (don't have netdev archived, thus answering here, sorry)
> >
> > On 2014-09-07 16:41:09 -0700, David Miller wrote:
> >> Alexan
mpossible that the bug has
existed for longer. It's also possible that this bug isn't the fault of
this patch. I think both aren't terribly likely though.
Greetings,
Andres Freund
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
Hi,
On 2014-07-29 15:52:46 +0900, Namhyung Kim wrote:
> On Mon, 28 Jul 2014 21:23:26 +0200, Andres Freund wrote:
> > On 2014-05-29 12:58:25 +0900, Namhyung Kim wrote:
> >> Now perf top and perf report will show children column by default if
> >> it has callchain inform
suddenly the default?
Greetings,
Andres Freund
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Hi Dave, Ted, All,
On 2014-05-23 16:42:47 +1000, Dave Chinner wrote:
> On Tue, Apr 29, 2014 at 01:57:14AM +0200, Andres Freund wrote:
> > Hi Dave,
> >
> > On 2014-04-29 09:47:56 +1000, Dave Chinner wrote:
> > > ping?
> >
> > I'd replied at htt
Commit-ID: 722a0d22d028bd74061cf582de1764884e73674f
Gitweb: http://git.kernel.org/tip/722a0d22d028bd74061cf582de1764884e73674f
Author: Andres Freund
AuthorDate: Fri, 9 May 2014 03:29:16 +0200
Committer: H. Peter Anvin
CommitDate: Fri, 9 May 2014 08:42:32 -0700
x86: Fix typo preventing
Commit-ID: c45f77364ba060395b7eff1bf45e6c537f913380
Gitweb: http://git.kernel.org/tip/c45f77364ba060395b7eff1bf45e6c537f913380
Author: Andres Freund
AuthorDate: Fri, 9 May 2014 03:29:17 +0200
Committer: H. Peter Anvin
CommitDate: Fri, 9 May 2014 08:42:47 -0700
x86: Fix typo in
Hi,
On 2014-05-09 09:54:52 +0200, Borislav Petkov wrote:
> On Fri, May 09, 2014 at 03:29:16AM +0200, Andres Freund wrote:
> > Due to a typo the msr accessor function introduced in
> > 22085a66c2fab6cf9b9393c056a3600a6b4735de didn't have any lasting
> > effects because t
ed on some cpus leading to
missing capabilities for those.
Signed-off-by: Andres Freund
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
---
arch/x86/lib/msr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/x86/lib/msr.c b/arch/x86/lib/msr.c
The spuriously added semicolon didn't have any effect because the
macro isn't currently in use.
c0a639ad0bc6b178b46996bd1f821a04643e2bde
Signed-off-by: Andres Freund
Cc: Borislav Petkov
Cc: H. Peter Anvin
Cc: Ingo Molnar
Cc: Thomas Gleixner
---
arch/x86/include/uapi/asm/msr-i
ble to
actually use the MSR_IA32_MISC_ENABLE_LIMIT_CPUID macro correctly.
Regards,
Andres Freund
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.ht
he behaviour you reported, but
> > the test program as it stands does not appear to be causing any
> > problems at all on the sort of storage I'd expect large databases to
> > be hosted on
A really really large number of database aren't stored on
Hi Dave,
On 2014-04-09 19:20:09 +1000, Dave Chinner wrote:
> On Wed, Mar 26, 2014 at 08:11:13PM +0100, Andres Freund wrote:
> > So, the average read time is less than one ms (SSD, and about 50% cached
> > workload). But once another backend does the fsync(), read latency
d as single node database server, so that's
possibly a sensible cutoff.
But then, I'd think that special many-socket machines are setup by
specialists, that'd know to enable if it makes sense...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant
linux/topology.h's comment about RECLAIM_DISTANCE should be
adapted as well.
Thanks,
Andres
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
To unsubscribe from this list: send the line "unsubscribe l
On 2014-03-26 14:41:31 -0700, Andy Lutomirski wrote:
> On Wed, Mar 26, 2014 at 12:11 PM, Andres Freund wrote:
> > Hi,
> >
> > At LSF/MM there was a slot about postgres' problems with the kernel. Our
> > top#1 concern is frequent slow read()s that happen while
ing the amount of dirty memory before
writeback on a per process basis.
* ...?
If somebody familiar with buffered IO writeback is around at LSF/MM, or
rather collab, Robert and I will be around for the next days.
Greetings,
Andres Freund
/*
* Portions Copyright (c) 2014, PostgreSQL Global De
On 2013-05-29 13:32:23 -0400, Johannes Weiner wrote:
> On Wed, May 29, 2013 at 04:53:12PM +0200, Andres Freund wrote:
> > On 2013-02-16 14:53:43 +1030, Rusty Russell wrote:
> > > Andrew Morton writes:
> > > > On Fri, 15 Feb 2013 18:13:04 -0500
> > > >
later, catching up]
I do. Postgres' could really use something like that for making saner
assumptions about the cost of doing an index/heap scan. postgres doesn't
use mmap() and mmaping larger files into memory isn't all that cheap
(32bit...) so having fincore would be nice.
On Thursday, September 27, 2012 06:19:53 PM Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 10:54 AM, Alex Deucher
wrote:
> > On Thu, Sep 27, 2012 at 9:23 AM, Andres Freund wrote:
> >> On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
> >>> On Thu, S
On Thursday, September 27, 2012 03:14:31 PM Alex Deucher wrote:
> On Thu, Sep 27, 2012 at 2:46 AM, Andres Freund wrote:
> > On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
> >> > -Original Message-
> >> > From: Andres Freund [mailt
On Wednesday, September 26, 2012 03:42:40 PM Deucher, Alexander wrote:
> > -Original Message-
> > From: Andres Freund [mailto:and...@anarazel.de]
> > Sent: Wednesday, September 26, 2012 9:41 AM
> > To: Dan Carpenter
> > Cc: Deucher, Alexander;
On Wednesday, September 26, 2012 03:00:09 PM Dan Carpenter wrote:
> This is fixed now?
Its been reverted in 2f1f4d9b60396d2df4cff829bd5376ffc8ed9a2c which is in rc6.
On Monday, September 17, 2012 09:30:12 PM Deucher, Alexander wrote:
Sorry, I somehow accidentally marked your email as read and thu
Hi,
On Friday, September 21, 2012 03:47:56 PM Jagdish Motwani wrote:
> Recently i upgraded my kernel from 2.6.29.6 to 2.6.35.14.
>
> After upgrading i got very poor performance on my postgre database.
>
>
> My test.sql contains 1 postgre insert query
>
>
> Linux 2.6.29.6
>
> time psql -
Hi,
On Monday, September 17, 2012 04:24:08 PM Deucher, Alexander wrote:
> > On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote:
> > > > While debugging another issue I upgraded from v3.6-rc4 to latest git
> > > > (which exactly is v3.6-rc6). After X started up one of my three
> > >
On Monday, September 17, 2012 03:16:56 PM Deucher, Alexander wrote:
> > -Original Message-
> > From: Andres Freund [mailto:and...@anarazel.de]
> > Sent: Monday, September 17, 2012 7:29 AM
> > To: LKML; Deucher, Alexander; David Airlie;
> > dri-de...@lists.f
1 - 100 of 109 matches
Mail list logo
