On Tue, Jun 16, Ian Campbell wrote:
> On Mon, 2015-06-15 at 19:58 +0200, Olaf Hering wrote:
> > On Mon, Jun 15, Andrew Cooper wrote:
> >
> > > In an ideal world, userspace tools like this should not really be tied
> > > to NR_CPUS or MAX_CPUS. They should get max_cpu_id from Xen and
> > > dynami
On Mon, 2015-06-15 at 19:58 +0200, Olaf Hering wrote:
> On Mon, Jun 15, Andrew Cooper wrote:
>
> > In an ideal world, userspace tools like this should not really be tied
> > to NR_CPUS or MAX_CPUS. They should get max_cpu_id from Xen and
> > dynamically allocate a bitmap of sufficient size.
>
>
On Mon, Jun 15, Andrew Cooper wrote:
> In an ideal world, userspace tools like this should not really be tied
> to NR_CPUS or MAX_CPUS. They should get max_cpu_id from Xen and
> dynamically allocate a bitmap of sufficient size.
The dumps are taken on one machine and get inspected on another, whi
On 15/06/15 17:14, Olaf Hering wrote:
> On Thu, Jun 11, George Dunlap wrote:
>
>> On 06/11/2015 12:03 PM, Julien Grall wrote:
>>> I would suggest some refactoring to remove NR_CPUS and associated code
>>> in order to avoid mis-usage later.
>>>
>>> Also, cpu_mask_t is a uint32_t, is it intentional?
On Thu, Jun 11, George Dunlap wrote:
> On 06/11/2015 12:03 PM, Julien Grall wrote:
> > I would suggest some refactoring to remove NR_CPUS and associated code
> > in order to avoid mis-usage later.
> >
> > Also, cpu_mask_t is a uint32_t, is it intentional?
>
> When xenalyze was originally written
On 06/11/2015 12:03 PM, Julien Grall wrote:
>
>
> On 11/06/2015 02:12, Olaf Hering wrote:
>> On Wed, Jun 10, Julien Grall wrote:
>>
>>> There is also a variable MAX_CPUS defined to 256. which is used every.
>>
>> You are right, while forwarding an old patch (from memory) I changed the
>> wrong pl
On 11/06/2015 02:12, Olaf Hering wrote:
On Wed, Jun 10, Julien Grall wrote:
There is also a variable MAX_CPUS defined to 256. which is used every.
You are right, while forwarding an old patch (from memory) I changed the
wrong place. MAX_CPUS is already at 256 so no change is strictly
necces
On Wed, Jun 10, Julien Grall wrote:
> There is also a variable MAX_CPUS defined to 256. which is used every.
You are right, while forwarding an old patch (from memory) I changed the
wrong place. MAX_CPUS is already at 256 so no change is strictly
neccessary.
I suggest to drop that patch from thi
Hi Olaf,
On 09/06/2015 07:23, Olaf Hering wrote:
To match the hypervisor default which was introduced in
9da0c5b63933b9912e3903190601661813954d0d, bump the limit.
Signed-off-by: Olaf Hering
Acked-by: George Dunlap
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
C
To match the hypervisor default which was introduced in
9da0c5b63933b9912e3903190601661813954d0d, bump the limit.
Signed-off-by: Olaf Hering
Acked-by: George Dunlap
Acked-by: Wei Liu
Cc: Ian Jackson
Cc: Stefano Stabellini
Cc: Ian Campbell
Cc: Wei Liu
---
tools/xentrace/analyze.h | 2 +-
1
10 matches
Mail list logo
