On Fri, Feb 05, 2010 at 04:03:33PM -0700, Jeff Ross wrote:
> Could I avoid all of this messing around if I had a server that could run
> amd64? How would a dual processor 1.8 Opteron 244 w/4GB ram compare to this
> 2.4GHZ dual XEON w/4GB ram? Bog knows I don't need another server, but...
amd64
2010/2/6 Jeff Ross :
> When I set shared_buffers to slightly less than 1/4 of my system ram I
> started this whole round of system panics and reports because in order to
> get postgres to start I then had to crank kern.shminfo.shmmax to 1GB, and
> that would trigger a panic very quickly under load.
Anton Maksimenkov wrote:
2010/2/5 Ted Unangst :
On Thu, Feb 4, 2010 at 2:21 PM, Jeff Ross wrote:
kern.shminfo.shmall=512000
kern.shminfo.shmmax=76800
Oh, when I said it was safe to crank shmmax I didn't know you'd be
setting the bufcache to huge numbers too. ;)
Furthermore, postgres do
2010/2/5 Anton Maksimenkov :
> set chared buffers to something not so big... say, 256Mb or so (I just
I misprint. Of course it's "shared", not "chared. Sorry.
--
antonvm
2010/2/5 Ted Unangst :
> On Thu, Feb 4, 2010 at 2:21 PM, Jeff Ross wrote:
>> kern.shminfo.shmall=512000
>> kern.shminfo.shmmax=76800
>
> Oh, when I said it was safe to crank shmmax I didn't know you'd be
> setting the bufcache to huge numbers too. ;)
Furthermore, postgres documentation recom
On Thu, Feb 4, 2010 at 2:21 PM, Jeff Ross wrote:
> kern.shminfo.shmall=512000
> kern.shminfo.shmmax=76800
Oh, when I said it was safe to crank shmmax I didn't know you'd be
setting the bufcache to huge numbers too. ;)
> available memory in the server. I tried setting mine to 980MBs (4GB of
Ariane van der Steldt wrote:
On Thu, Feb 04, 2010 at 09:29:13AM -0700, Jeff Ross wrote:
Jeff Ross wrote:
On Sat, 30 Jan 2010, Bob Beck wrote:
Ooooh. nice one. Obviously ami couldn't get memory mappings and
freaked out.
While not completely necessary, I'd love for you to file that whole
thi
On Thu, Feb 04, 2010 at 09:29:13AM -0700, Jeff Ross wrote:
> Jeff Ross wrote:
> > On Sat, 30 Jan 2010, Bob Beck wrote:
> >
> >> Ooooh. nice one. Obviously ami couldn't get memory mappings and
> >> freaked out.
> >>
> >> While not completely necessary, I'd love for you to file that whole
> >> thi
Jeff Ross wrote:
On Sat, 30 Jan 2010, Bob Beck wrote:
Ooooh. nice one. Obviously ami couldn't get memory mappings and
freaked out.
While not completely necessary, I'd love for you to file that whole
thing into sendbug() in a pr so we don't
forget it. but that one I need to pester krw, art, d
On Mon, Feb 01, 2010 at 03:59:24PM -0700, Bob Beck wrote:
> On 1 February 2010 10:41, Ted Unangst wrote:
>
> >> I think the pool allocator is doable. Will look at it when I get a spare
> >> hour or two (may be a while ;)
> >
> > Noo!!!
> >
> > Y
of buzzwords.
>
Knock it off both of you fer crissake. Jeesus what a what to take a
productive thread and turn it into a shitshow. Take this conversation
to misc@ please so it doesn't hit my inbox.
Yes the "ubc" buzzword was in the initial thread, which is why I asked
the question
come out when you have a idea but don't know quite
> > > > how to express it. which is clearly the situation here.
> > >
> > > It's not like UBC was totally unrelated to the topic. And that situation
> > > was already handled fine by Bob Beck
t
> > > that reply was about, buzzwords. there was nothing personal. see,
> > > the way buzzwords work, is they get stuck in your (as in most people)
> > > head, then they come out when you have a idea but don't know quite
> > > how to express it. which
ee,
> > the way buzzwords work, is they get stuck in your (as in most people)
> > head, then they come out when you have a idea but don't know quite
> > how to express it. which is clearly the situation here.
>
> It's not like UBC was totally unrelated to the topic
; head, then they come out when you have a idea but don't know quite
> how to express it. which is clearly the situation here.
It's not like UBC was totally unrelated to the topic. And that situation
was already handled fine by Bob Beck in a more productive and
informative way.
>
: jake...@sdf.lonestar.org
> To: tech@openbsd.org
> Subject: Re: UBC?
>
> On Mon, Feb 01, 2010 at 03:28:22PM -0700, Darrin Chandler wrote:
> > On Mon, Feb 01, 2010 at 03:05:37PM -0700, Nick Bender wrote:
> > > On Mon, Feb 1, 2010 at 2:46 PM, Bob Beck wrote:
> > > >
ing the flow of
> > > technical information a it, but you choose not to.
> >
> > Civility is in the eye of the moderator. I prefer my debate unfiltered...
>
> There was some belittling of Allen for asking about UBC. I don't think
> it added anything. Not even h
On 1 February 2010 10:41, Ted Unangst wrote:
>> I think the pool allocator is doable. Will look at it when I get a spare
>> hour or two (may be a while ;)
>
> Noo!!!
>
> You are begging for pain. Multi backend allocators have not fared well.
>
; > You could enforce minimum levels
> > of civility, as many such communities do, without impeding the flow of
> > technical information a it, but you choose not to.
>
> Civility is in the eye of the moderator. I prefer my debate unfiltered...
There was some belittling of Alle
On Mon, Feb 1, 2010 at 2:46 PM, Bob Beck wrote:
> On 1 February 2010 14:09, Donald Allen wrote:
>> I have not responded to this thread because I was angered by it and
>> did not want to respond in anger. That has passed. But this thread is
>> unfortunately all too typical of a pattern of ridicule
On 1 February 2010 14:09, Donald Allen wrote:
> I have not responded to this thread because I was angered by it and
> did not want to respond in anger. That has passed. But this thread is
> unfortunately all too typical of a pattern of ridicule and downright
> nastiness that occurs much too often
I have not responded to this thread because I was angered by it and
did not want to respond in anger. That has passed. But this thread is
unfortunately all too typical of a pattern of ridicule and downright
nastiness that occurs much too often on the OpenBSD lists. It's
unfortunate that you do this
On Mon, Feb 1, 2010 at 4:08 AM, Artur Grabowski wrote:
> caller holds lock on kernel_map. getpage pool is empty, caller wakes
> up the getpage thread, goes to sleep (still holding the kernel_map
> lock), getpage thread wakes up, deadlocks on the kernel_map lock. It's
> not an easily detectable rec
On Mon, Feb 1, 2010 at 9:07 AM, Owain Ainsworth wrote:
> On Mon, Feb 01, 2010 at 10:08:08AM +0100, Artur Grabowski wrote:
>> We could try some magic with allocating from a pool with NOWAIT and
>> then fall back to kmem_map when that fails, but the logic would become
>> hairy. Maybe a pool allocato
On Mon, Feb 01, 2010 at 10:08:08AM +0100, Artur Grabowski wrote:
> Ariane van der Steldt writes:
>
> > Why are the pventries allocated from the kmem_map anyway? I think they
> > should be allocated using the uvm_km_getpage instead. Or even better,
> > from a pvpool like amd64.
>
> Recursion.
>
Ariane van der Steldt writes:
> Why are the pventries allocated from the kmem_map anyway? I think they
> should be allocated using the uvm_km_getpage instead. Or even better,
> from a pvpool like amd64.
Recursion.
caller holds lock on kernel_map. getpage pool is empty, caller wakes
up the getpa
On Sun, Jan 31, 2010 at 12:15:58PM -0701, Jeff Ross wrote:
> On Sat, 30 Jan 2010, Bob Beck wrote:
>
> > Ooooh. nice one. Obviously ami couldn't get memory mappings and freaked
> > out.
> >
> > While not completely necessary, I'd love for you to file that whole
> > thing into sendbug() in a pr so
On Sat, Jan 30, 2010 at 3:50 PM, David Gwynne wrote:
...
> - am = malloc(sizeof(struct ami_mem), M_DEVBUF, M_NOWAIT|M_ZERO);
> + am = malloc(sizeof(struct ami_mem), M_DEVBUF, M_ZERO |
> + nowait ? M_NOWAIT : 0);
Oops, precedence lossage! That always passes M_NOWAIT (and nev
On Sat, 30 Jan 2010, Bob Beck wrote:
Ooooh. nice one. Obviously ami couldn't get memory mappings and freaked out.
While not completely necessary, I'd love for you to file that whole
thing into sendbug() in a pr so we don't
forget it. but that one I need to pester krw, art, dlg, and maybe
marco
On Sun, Jan 31, 2010 at 01:18:59PM +, Stuart Henderson wrote:
> On 2010/01/31 09:50, David Gwynne wrote:
> > On Sun, Jan 31, 2010 at 09:41:14AM +1000, David Gwynne wrote:
> > > pmap_enter in this situation should fail, not panic. the error would be
> > > handled properly as the stack unwinds u
On 2010/01/31 09:50, David Gwynne wrote:
> On Sun, Jan 31, 2010 at 09:41:14AM +1000, David Gwynne wrote:
> > pmap_enter in this situation should fail, not panic. the error would be
> > handled properly as the stack unwinds up to ami_allocmem.
> >
> > i can change ami_allocmem to take a NOWAIT etc
On Sun, Jan 31, 2010 at 09:41:14AM +1000, David Gwynne wrote:
> pmap_enter in this situation should fail, not panic. the error would be
> handled properly as the stack unwinds up to ami_allocmem.
>
> i can change ami_allocmem to take a NOWAIT etc as an argument rather than
> just assume it, so c
eriments with a Linux system running on comparable hardware
>>>> (same amount of memory -- 2 Gb) and got the caching behavior I
>>>> expected.
>>>
>>> So what you are asking for is a bigger buffer cache, not "ubc"
>>>
>>> 1)
On Sat, 30 Jan 2010, Bob Beck wrote:
> >> > http://professionalsuperhero.com/
> >>
> >> That link isn't in iCal format; I can't open it in my scheduler.
> >
> > You need a pluggable scheduler system, like what has been proposed
> > for Linux.
> >
>
> Now you're just taunting me to try to make me
t;>> experimenting with vmstat running confirmed this. I then tried the
>>> same experiments with a Linux system running on comparable hardware
>>> (same amount of memory -- 2 Gb) and got the caching behavior I
>>> expected.
>>
>> So what you are asking for i
experimenting with vmstat running confirmed this. I then tried the
same experiments with a Linux system running on comparable hardware
(same amount of memory -- 2 Gb) and got the caching behavior I
expected.
So what you are asking for is a bigger buffer cache, not "ubc"
1) install current
2)
>> > http://professionalsuperhero.com/
>>
>> That link isn't in iCal format; I can't open it in my scheduler.
>
> You need a pluggable scheduler system, like what has been proposed
> for Linux.
>
Now you're just taunting me to try to make me explode. Probably
because I henninged your wall.. Did t
On Fri, 29 Jan 2010, Bret S. Lambert wrote:
> On Fri, Jan 29, 2010 at 01:47:09PM -0700, Bob Beck wrote:
> > > Well, to be fair, he was asking for $buzzword. So we could load
> > > him up with some Customer-Facing Enterprise Extranet Bundles,
> > > served over XML in a proactive win-win paradigm.
>
On Fri, Jan 29, 2010 at 01:47:09PM -0700, Bob Beck wrote:
> > Well, to be fair, he was asking for $buzzword. So we could load
> > him up with some Customer-Facing Enterprise Extranet Bundles,
> > served over XML in a proactive win-win paradigm.
> >
> > Then his disk reads would be all like "zoom!!!
> Well, to be fair, he was asking for $buzzword. So we could load
> him up with some Customer-Facing Enterprise Extranet Bundles,
> served over XML in a proactive win-win paradigm.
>
> Then his disk reads would be all like "zoom!!!"
>
> Or, for brevity's sake: there is no spoon.
http://professiona
; > expected.
>
> So what you are asking for is a bigger buffer cache, not "ubc"
Well, to be fair, he was asking for $buzzword. So we could load
him up with some Customer-Facing Enterprise Extranet Bundles,
served over XML in a proactive win-win paradigm.
Then his disk reads
erimenting with vmstat running confirmed this. I then tried the
> same experiments with a Linux system running on comparable hardware
> (same amount of memory -- 2 Gb) and got the caching behavior I
> expected.
So what you are asking for is a bigger buffer cache, not "ubc"
m a "unified buffer cache" - mmap
coherency?
>>
>> Because things are being worked on, however we just may not be doing
>> it the way you are thinking.
>>
>> So let me be clear - UBC is a particular way of implementing things.
>> What "things"
are being worked on, however we just may not be doing
> it the way you are thinking.
>
> So let me be clear - UBC is a particular way of implementing things.
> What "things" are you looking
> for from UBC - because we may already be doing that without UBC.
My question was m
So let me be clear - UBC is a particular way of implementing things.
What "things" are you looking
for from UBC - because we may already be doing that without UBC.
2010/1/29 Bret S. Lambert :
> On Fri, Jan 29, 2010 at 11:17:07AM -0500, Donald Allen wrote:
>> Any developers care
go, some bad things happened, and the change got backed out.
> Looking at the code, it looks like there is some conditional ubc code
> that appears not to be included in the current release. Have I got
> this right -- OpenBSD doesn't provide a unified buffer cache at this
> time?
looks like there is some conditional ubc code
that appears not to be included in the current release. Have I got
this right -- OpenBSD doesn't provide a unified buffer cache at this
time?
/Don Allen
47 matches
Mail list logo
