Grokbase › Groups › Go › golang-nuts › November 2013
FAQ
right now it seems like we're at 128gb max
--- https://code.google.com/p/go/source/detail?r=a310cb32c278 --- so does
anybody have any concrete ideas on or understanding of how to double that
to 256gb? since i'd love to use all 244gb memory on amazon's cr1.8xlarge
machine type. would i simply follow a similar pattern as russ did in his
changes, or are there more subtle issues involved and thus a different kind
of solution might be called for?


--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Ian Lance Taylor at Nov 4, 2013 at 4:59 pm ⇧

    On Mon, Nov 4, 2013 at 1:58 AM, Mike Andrews wrote:
    right now it seems like we're at 128gb max ---
    https://code.google.com/p/go/source/detail?r=a310cb32c278 --- so does
    anybody have any concrete ideas on or understanding of how to double that to
    256gb? since i'd love to use all 244gb memory on amazon's cr1.8xlarge
    machine type. would i simply follow a similar pattern as russ did in his
    changes, or are there more subtle issues involved and thus a different kind
    of solution might be called for?
    I'm not aware of any subtleties here. You should be able to just bump
    the numbers.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Voidlogic at Nov 4, 2013 at 8:41 pm ⇧
    I might be remembering this incorrectly, but I think this isn't bumped up
    by default because the bookkeeping structures have a virtual memory
    footprint at runtime startup (which is fairy significant at 256 GB). And
    systems with limited memory to begin with and poor VM accounting (windows)
    are unhappy with a large runtime VM footprint.
    On Monday, November 4, 2013 10:58:59 AM UTC-6, Ian Lance Taylor wrote:

    On Mon, Nov 4, 2013 at 1:58 AM, Mike Andrews <[email protected] <javascript:>>
    wrote:
    right now it seems like we're at 128gb max ---
    https://code.google.com/p/go/source/detail?r=a310cb32c278 --- so does
    anybody have any concrete ideas on or understanding of how to double that to
    256gb? since i'd love to use all 244gb memory on amazon's cr1.8xlarge
    machine type. would i simply follow a similar pattern as russ did in his
    changes, or are there more subtle issues involved and thus a different kind
    of solution might be called for?
    I'm not aware of any subtleties here. You should be able to just bump
    the numbers.

    Ian
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dmitry Vyukov at Nov 9, 2013 at 1:12 pm ⇧
    sent from phone
    On Nov 4, 2013 10:41 PM, "voidlogic" wrote:

    I might be remembering this incorrectly, but I think this isn't bumped up
    by default because the bookkeeping structures have a virtual memory
    footprint at runtime startup (which is fairy significant at 256 GB).

    That memory is allocated on demand now.

    And systems with limited memory to begin with and poor VM accounting
    (windows) are unhappy with a large runtime VM footprint.
    On Monday, November 4, 2013 10:58:59 AM UTC-6, Ian Lance Taylor wrote:
    On Mon, Nov 4, 2013 at 1:58 AM, Mike Andrews wrote:
    right now it seems like we're at 128gb max ---
    https://code.google.com/p/go/source/detail?r=a310cb32c278 --- so does
    anybody have any concrete ideas on or understanding of how to double
    that to
    256gb? since i'd love to use all 244gb memory on amazon's cr1.8xlarge
    machine type. would i simply follow a similar pattern as russ did in
    his
    changes, or are there more subtle issues involved and thus a different
    kind
    of solution might be called for?
    I'm not aware of any subtleties here. You should be able to just bump
    the numbers.

    Ian
    --
    You received this message because you are subscribed to the Google Groups
    "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an
    email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
  • Dan Kortschak at Nov 4, 2013 at 9:46 pm ⇧
    There are some comments in malloc.goc#L329 talking about preciseness and unicode code points as part of the reason for the choice. Would choosing larger values increase the likelihood of GC leaks because of GC imprecision?
    On 05/11/2013, at 3:29 AM, "Ian Lance Taylor" wrote:
    On Mon, Nov 4, 2013 at 1:58 AM, Mike Andrews wrote:
    right now it seems like we're at 128gb max ---
    https://code.google.com/p/go/source/detail?r=a310cb32c278 --- so does
    anybody have any concrete ideas on or understanding of how to double that to
    256gb? since i'd love to use all 244gb memory on amazon's cr1.8xlarge
    machine type. would i simply follow a similar pattern as russ did in his
    changes, or are there more subtle issues involved and thus a different kind
    of solution might be called for?
    I'm not aware of any subtleties here. You should be able to just bump
    the numbers.

    Ian

    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.
    --
    You received this message because you are subscribed to the Google Groups "golang-nuts" group.
    To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedNov 4, '13 at 9:58a
activeNov 9, '13 at 1:12p
posts5
users5
websitegolang.org

5 users in discussion

Dmitry Vyukov: 1 post Ian Lance Taylor: 1 post Mike Andrews: 1 post Voidlogic: 1 post Dan Kortschak: 1 post

Content

People

Support

Translate

site design / logo © 2023 Grokbase