[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-devel] [PATCH v12 for-xen-4.5 11/20] x86/VPMU: Interface for setting PMU mode and flags
 
- To: Dietmar Hahn <dietmar.hahn@xxxxxxxxxxxxxx>, xen-devel@xxxxxxxxxxxxx
 
- From: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx>
 
- Date: Mon, 29 Sep 2014 09:56:50 -0400
 
- Cc: kevin.tian@xxxxxxxxx, keir@xxxxxxx, jbeulich@xxxxxxxx,	jun.nakajima@xxxxxxxxx, andrew.cooper3@xxxxxxxxxx, tim@xxxxxxx,	Aravind.Gopalakrishnan@xxxxxxx, suravee.suthikulpanit@xxxxxxx,	dgdegra@xxxxxxxxxxxxx
 
- Delivery-date: Mon, 29 Sep 2014 13:55:59 +0000
 
- List-id: Xen developer discussion <xen-devel.lists.xen.org>
 
 
 
On 09/29/2014 09:25 AM, Dietmar Hahn wrote:
 
+static int vpmu_force_context_switch(void)
+{
+    unsigned i, j, allbutself_num, mycpu;
+    static s_time_t start, now;
+    struct tasklet **sync_task;
+    struct vcpu *curr_vcpu = current;
+    int ret = 0;
+
+    allbutself_num = num_online_cpus() - 1;
+
+    sync_task = xzalloc_array(struct tasklet *, allbutself_num);
+    if ( !sync_task )
+    {
+        printk(XENLOG_WARNING "vpmu_force_context_switch: out of memory\n");
+        return -ENOMEM;
+    }
+
+    for ( i = 0; i < allbutself_num; i++ )
+    {
+        sync_task[i] = xmalloc(struct tasklet);
+        if ( sync_task[i] == NULL )
+        {
+            printk(XENLOG_WARNING "vpmu_force_context_switch: out of 
memory\n");
+            ret = -ENOMEM;
+            goto out;
+        }
+        tasklet_init(sync_task[i], vpmu_sched_checkin, 0);
Only a question of understanding.
Is there a special reason not to use a single memory allocation
except for memory fragmentation on systems with a large number of cpus?
      struct tasklet *sync_task;
      sync_task = xmalloc(sizeof(struct tasklet) * allbutself_num);
 
 Exactly because of fragmentation -- this will avoid asking for more than 
a page during runtime. I, in fact, originally had it allocated as a 
single chunk, just as you suggested above, but Jan asked this to be 
split into smaller, sub-page pieces.
-boris
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel
 
 
    
     |