On 1/22/18 01:10, Thomas Munro wrote:
> Sorry, right, that was 100% wrong. It would probably be correct to
> remove the "not", but let's just remove that bit. New version
> attached.
Committed that.
I reordered some of the existing material because it seemed to have
gotten a bit out of order wi
On Wed, Jan 24, 2018 at 07:46:41AM +0100, Catalin Iacob wrote:
> I see Peter assigned himself as committer, some more information below
> for him to decide on the strength of the anti THP message.
Thanks for digging this up!
> And it would be good if somebody could run benchmarks on pre 4.6 and
>
On Tue, Jan 23, 2018 at 7:13 PM, Catalin Iacob wrote:
> By the way, Fedora 27 does disable THP by default, they deviate from
> upstream in this regard:
> When I have some time I'll try to do some digging into history of the
> Fedora kernel package to see if they provide a rationale for changing
>
On Mon, Jan 22, 2018 at 7:23 AM, Justin Pryzby wrote:
> Consider this shorter, less-severe sounding alternative:
> "... (but note that this feature can degrade performance of some
> PostgreSQL workloads)."
I think the patch looks good now.
As Justin mentions, as far as I see the only arguable pi
On Mon, Jan 22, 2018 at 07:10:33PM +1300, Thomas Munro wrote:
> On Mon, Jan 22, 2018 at 6:30 PM, Justin Pryzby wrote:
> > On Mon, Jan 22, 2018 at 03:54:26PM +1300, Thomas Munro wrote:
> >> On Fri, Jan 12, 2018 at 1:12 PM, Thomas Munro
> >> wrote:
> >> > On Tue, Jan 9, 2018 at 6:24 AM, Catalin Iac
On Mon, Jan 22, 2018 at 6:30 PM, Justin Pryzby wrote:
> On Mon, Jan 22, 2018 at 03:54:26PM +1300, Thomas Munro wrote:
>> On Fri, Jan 12, 2018 at 1:12 PM, Thomas Munro
>> wrote:
>> > On Tue, Jan 9, 2018 at 6:24 AM, Catalin Iacob
>> > wrote:
>> > I don't know enough about this to make such a stro
On Mon, Jan 22, 2018 at 03:54:26PM +1300, Thomas Munro wrote:
> On Fri, Jan 12, 2018 at 1:12 PM, Thomas Munro
> wrote:
> > On Tue, Jan 9, 2018 at 6:24 AM, Catalin Iacob
> > wrote:
> > I don't know enough about this to make such a strong recommendation
> > myself, which is why I was only trying t
On Fri, Jan 12, 2018 at 1:12 PM, Thomas Munro
wrote:
> On Tue, Jan 9, 2018 at 6:24 AM, Catalin Iacob wrote:
>> So I tried to redo the second paragraph and ended up with the
>> attached. Rationale for the changes:
>> * changed "this feature" to "explicitly requesting huge pages" to
>> contrast wit
On 12/1/17 10:08, Peter Eisentraut wrote:
> Part of the confusion is that the huge_pages setting is only for shared
> memory, whereas the kernel settings affect all memory. Is the same true
> for the proposed Windows patch?
Btw., I'm kind of hoping that the Windows patch would be committed
first,
On Tue, Jan 9, 2018 at 6:24 AM, Catalin Iacob wrote:
> On Fri, Dec 1, 2017 at 10:09 PM, Thomas Munro
> wrote:
>>> On 11/30/17 23:35, Thomas Munro wrote:
Hmm. Yeah, it does, but apparently it's not so transparent. So if we
mention that we'd better indicate in the same paragraph that yo
On Fri, Dec 1, 2017 at 10:09 PM, Thomas Munro
wrote:
>> On 11/30/17 23:35, Thomas Munro wrote:
>>> Hmm. Yeah, it does, but apparently it's not so transparent. So if we
>>> mention that we'd better indicate in the same paragraph that you
>>> probably don't actually want to use it. How about the
On Mon, Dec 04, 2017 at 09:48:44AM +0100, Adrien Nayrat wrote:
> On 12/01/2017 05:35 AM, Thomas Munro wrote:
> >> since it also supports "transparent" hugepages.
> > Hmm. Yeah, it does, but apparently it's not so transparent.
>
> +1. We saw performance drop with transparent_hugepage enabled on s
On 12/01/2017 05:35 AM, Thomas Munro wrote:
>> since it also
>> supports "transparent" hugepages.
> Hmm. Yeah, it does, but apparently it's not so transparent.
+1. We saw performance drop with transparent_hugepage enabled on server with
more than 256GB RAM. Access to the cache where slow down wh
On Sat, Dec 2, 2017 at 4:08 AM, Peter Eisentraut
wrote:
> On 11/30/17 23:35, Thomas Munro wrote:
>> On Fri, Dec 1, 2017 at 5:04 PM, Justin Pryzby wrote:
>>> On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
Hi hackers,
The manual implies that only Linux can use huge pag
On 11/30/17 23:35, Thomas Munro wrote:
> On Fri, Dec 1, 2017 at 5:04 PM, Justin Pryzby wrote:
>> On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
>>> Hi hackers,
>>>
>>> The manual implies that only Linux can use huge pages. That is not
>>> true: FreeBSD, Illumos and probably others
On Fri, Dec 1, 2017 at 5:04 PM, Justin Pryzby wrote:
> On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
>> Hi hackers,
>>
>> The manual implies that only Linux can use huge pages. That is not
>> true: FreeBSD, Illumos and probably others support larger page sizes
>> using transparent
On Fri, Dec 01, 2017 at 04:01:24PM +1300, Thomas Munro wrote:
> Hi hackers,
>
> The manual implies that only Linux can use huge pages. That is not
> true: FreeBSD, Illumos and probably others support larger page sizes
> using transparent page coalescing algorithms. On my FreeBSD box
> procstat -
17 matches
Mail list logo
