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 jr...@openvistas.net:
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
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
thing into sendbug()
On Thu, Feb 4, 2010 at 2:21 PM, Jeff Ross jr...@openvistas.net 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
2010/2/5 Ted Unangst ted.unan...@gmail.com:
On Thu, Feb 4, 2010 at 2:21 PM, Jeff Ross jr...@openvistas.net 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. ;)
2010/2/5 Anton Maksimenkov anton...@gmail.com:
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
On Mon, Feb 01, 2010 at 03:59:24PM -0700, Bob Beck wrote:
On 1 February 2010 10:41, Ted Unangst ted.unan...@gmail.com 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!!!
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 b...@ualberta.ca wrote:
On 1 February 2010 14:09, Donald Allen donaldcal...@gmail.com
wrote:
I have
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.
I think readers of OpenBSD lists are far too
, 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. And that situation
was already handled fine by Bob Beck in a more
, 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 is clearly the situation here.
It's not like UBC was totally unrelated to the topic
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.
I think readers of OpenBSD lists are far too sensitive. there, that's
a personal 'attack' on all y'all
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 questions, and why it then went somewhere. Get over it. If the OP
Ariane van der Steldt ari...@stack.nl 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
On Mon, Feb 01, 2010 at 10:08:08AM +0100, Artur Grabowski wrote:
Ariane van der Steldt ari...@stack.nl 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.
On Mon, Feb 1, 2010 at 9:07 AM, Owain Ainsworth zer...@googlemail.com 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
On Mon, Feb 1, 2010 at 4:08 AM, Artur Grabowski a...@blahonga.org 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
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
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 humor. Beck's initial response was a good
one, clarifying and offering something to try
On 1 February 2010 10:41, Ted Unangst ted.unan...@gmail.com 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
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 Allen for asking about UBC. I don't think
it added anything
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 as an
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 up to
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
On Sat, Jan 30, 2010 at 3:50 PM, David Gwynne l...@animata.net 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
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 we don't
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 the
wine
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 explode. Probably
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
, 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?
/Don Allen
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?
There is no spoon.
/Don Allen
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 motivated by noticing that repeated accesses to a
fairly large file
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) sysctl -w
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.
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!!!
Or,
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.
Then
36 matches
Mail list logo
