On Wed, Sep 29, 2010 at 1:54 PM, Robert N. M. Watson
wrote:
>
> On 29 Sep 2010, at 12:49, John Baldwin wrote:
>
>> On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote:
>>>
>>> On 28 Sep 2010, at 19:40, Sean Bruno wrote:
>>>
> If you go fully dynamic you should use mp_maxid + 1
On 29 Sep 2010, at 12:49, John Baldwin wrote:
> On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote:
>>
>> On 28 Sep 2010, at 19:40, Sean Bruno wrote:
>>
If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus.
>>>
>>> I assume that mp_maxid is the new kern
On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote:
>
> On 28 Sep 2010, at 19:40, Sean Bruno wrote:
>
> >> If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus.
> >
> > I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some
> > history here s
On 28 Sep 2010, at 19:40, Sean Bruno wrote:
>> If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus.
>
> I assume that mp_maxid is the new kern.smp.maxcpus? Can you inject some
> history here so I can understand why one is "better" than the other?
So, unlike maxcpus, mp_maxi
On Tue, 2010-09-28 at 14:06 -0500, John Baldwin wrote:
> On Tuesday, September 28, 2010 2:40:44 pm Sean Bruno wrote:
> > On Tue, 2010-09-28 at 13:29 -0500, John Baldwin wrote:
> > > On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote:
> > > > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson
On Tuesday, September 28, 2010 2:40:44 pm Sean Bruno wrote:
> On Tue, 2010-09-28 at 13:29 -0500, John Baldwin wrote:
> > On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote:
> > > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote:
> > > > On Mon, 27 Sep 2010, Joshua Neal wrote:
> > > >
On Tue, 2010-09-28 at 13:29 -0500, John Baldwin wrote:
> On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote:
> > On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote:
> > > On Mon, 27 Sep 2010, Joshua Neal wrote:
> > >
> > > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU.
On Tuesday, September 28, 2010 12:45:11 pm Sean Bruno wrote:
> On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote:
> > On Mon, 27 Sep 2010, Joshua Neal wrote:
> >
> > > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's
> > > already
> > > asking the kernel for the max number
On 28 Sep 2010, at 17:45, Sean Bruno wrote:
> Working on a dynamic version today. I'll spam it over to you for review
> later.
>
> I'm moving the percpu struct definitions outside of struct memory_type,
> allocating quantity kern.smp.maxcpus, removing the boundary checks based
> on MEMSTAT_MA
On Tue, 2010-09-28 at 02:48 -0500, Robert Watson wrote:
> On Mon, 27 Sep 2010, Joshua Neal wrote:
>
> > I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already
> > asking the kernel for the max number and throwing an error if it doesn't
> > agree:
>
> Yes, it looks like MAXCP
On Mon, 27 Sep 2010, Joshua Neal wrote:
I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's already
asking the kernel for the max number and throwing an error if it doesn't
agree:
Yes, it looks like MAXCPU was bumped in the kernel without bumping the limit
in libmemstat. The
I hit this bug at one point, and had to bump MEMSTAT_MAXCPU. It's
already asking the kernel for the max number and throwing an error if
it doesn't agree:
if (sysctlbyname("kern.smp.maxcpus", &maxcpus, &size, NULL, 0) < 0) {
[...]
if (maxcpus > MEMSTAT_MAXCPU) {
li
On Mon, 27 Sep 2010, John Baldwin wrote:
Also, I think we should either fix MAXCPU to export the SMP value to
userland, or hide it from userland completely. Exporting the UP value is
Just Wrong (tm).
Well, it's useful in the sense that it tells you what the maximum number of
CPUs a kernel
On Monday, September 27, 2010 5:21:31 pm Robert Watson wrote:
>
> On Mon, 27 Sep 2010, Sean Bruno wrote:
>
> >> wouldn't it be better to do a sysctlbyname() and use the real value for
> >> the
> >> system?
>
> libmemstat contains some useful sample code showing how this might be done.
>
> > T
On Mon, 2010-09-27 at 12:41 -0500, Attilio Rao wrote:
> 2010/9/27 Sean Bruno :
> > On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote:
> >> On 9/27/10 8:26 AM, Sean Bruno wrote:
> >> > Does this look like an appropriate modification to libmemstat?
> >> >
> >> > Sean
> >> >
> >> >
> >> >
On Mon, 27 Sep 2010, Sean Bruno wrote:
wouldn't it be better to do a sysctlbyname() and use the real value for the
system?
libmemstat contains some useful sample code showing how this might be done.
That was my initial thought (as prodded by scottl and peter).
If it is made dynamic, could
On Mon, 27 Sep 2010, Scott Long wrote:
There's no reason not to include . I'm a little reluctant to
have it depend on the static MAXCPU definition, though. What happens when
you mix-and match userland and kernel and they no longer agree on the
definition of MAXCPU? I suggest creating a sys
On Mon, Sep 27, 2010 at 9:21 AM, Sean Bruno wrote:
> On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote:
>> On 9/27/10 8:26 AM, Sean Bruno wrote:
>> > Does this look like an appropriate modification to libmemstat?
>> >
>> > Sean
>> >
>> >
>> > //depot/yahoo/ybsd_7/src/lib/libmemstat/mem
2010/9/27 Sean Bruno :
> On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote:
>> On 9/27/10 8:26 AM, Sean Bruno wrote:
>> > Does this look like an appropriate modification to libmemstat?
>> >
>> > Sean
>> >
>> >
>> > //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4
>> > - /home/seanbru
On Mon, 2010-09-27 at 08:53 -0700, Julian Elischer wrote:
> On 9/27/10 8:26 AM, Sean Bruno wrote:
> > Does this look like an appropriate modification to libmemstat?
> >
> > Sean
> >
> >
> > //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4
> > - /home/seanbru/ybsd_7/src/lib/libmemstat/memsta
>
> I would not include sys/param and would axe out the comment.
>
> Just make sure anything compiles with these modifies eventually.
>
> Thanks,
> Attilio
>
>
Ah, yes. The include is completely pointless. The value can be
assigned without it.
Sean
=== //depot/yahoo/ybsd_7/src/lib/libmem
2010/9/27 Sean Bruno :
> Does this look like an appropriate modification to libmemstat?
>
> Sean
>
>
> //depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4
> - /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h
> @@ -28,12 +28,13 @@
>
> #ifndef _MEMSTAT_H_
> #define _MEMSTAT_H_
> +
There's no reason not to include . I'm a little reluctant to have
it depend on the static MAXCPU definition, though. What happens when you
mix-and match userland and kernel and they no longer agree on the definition of
MAXCPU? I suggest creating a sysctl that exports the kernel's definition o
On 9/27/10 8:26 AM, Sean Bruno wrote:
Does this look like an appropriate modification to libmemstat?
Sean
//depot/yahoo/ybsd_7/src/lib/libmemstat/memstat.h#4
- /home/seanbru/ybsd_7/src/lib/libmemstat/memstat.h
@@ -28,12 +28,13 @@
#ifndef _MEMSTAT_H_
#define_MEMSTAT_H_
+
24 matches
Mail list logo
