On Mon, Mar 14, 2005 at 05:39:54PM -0800, Chandra Seetharaman wrote:
>
> --
>
> ----------------------------------------------------------------------
> Chandra Seetharaman | Be careful what you choose....
> - [EMAIL PROTECTED] | .......you may get it.
> ----------------------------------------------------------------------
> Patch 1 of 6 patches to support memory controller under CKRM framework.
> This patch has the basic changes needed to get the hooks in the appropriate
> kernel functions to get control in the controller.
>
> Index: 2611-rc5-numem/fs/exec.c
> ===================================================================
> --- 2611-rc5-numem.orig/fs/exec.c
> +++ 2611-rc5-numem/fs/exec.c
> @@ -49,6 +49,7 @@
> #include <linux/rmap.h>
> #include <linux/acct.h>
> #include <linux/ckrm_events.h>
> +#include <linux/ckrm_mem_inline.h>
>
> #include <asm/uaccess.h>
> #include <asm/mmu_context.h>
> @@ -573,6 +574,7 @@ static int exec_mmap(struct mm_struct *m
> activate_mm(active_mm, mm);
> task_unlock(tsk);
> arch_pick_mmap_layout(mm);
> + ckrm_task_mm_change(tsk, old_mm, mm);
> if (old_mm) {
> up_read(&old_mm->mmap_sem);
> if (active_mm != old_mm) BUG();
> Index: 2611-rc5-numem/include/linux/ckrm_mem.h
> ===================================================================
> --- 2611-rc5-numem.orig/include/linux/ckrm_mem.h
> +++ 2611-rc5-numem/include/linux/ckrm_mem.h
> @@ -0,0 +1,27 @@
> +/* include/linux/ckrm_mem.h : memory control for CKRM
> + *
> + * Copyright (C) Jiantao Kong, IBM Corp. 2003
> + * (C) Shailabh Nagar, IBM Corp. 2003
> + * (C) Chandra Seetharaman, IBM Corp. 2004
> + *
> + *
> + * Memory control functions of the CKRM kernel API
> + *
> + * Latest version, more details at http://ckrm.sf.net
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + */
> +
> +#ifndef _LINUX_CKRM_MEM_H
> +#define _LINUX_CKRM_MEM_H
> +
> +/*
> + * Adding the file just to have the files that include this intact
> + * in later patches.
> + */
> +
> +#endif /* _LINUX_CKRM_MEM_H */
Just something general to these patches. The idea of splitting patches
up into logically smaller chunks does not mean you should create empty
files. A patch like this will get rejected straight-off by LKML. There
is no need to create the file in this patch [1/6] and then remove a few
lines and add the rest of the file in a separate patch [2/6]. I think
all of it can go in [2/6]. Something similar occurs with the next chunk,
where you have the #error which gets replaced immediately by the other
patch.
It may just be easier to split up your patch by subsystem: core kernel
interface changes (not in mm/), core VMM (in mm/) changes, core CKRM
changes (include/linux/ckrm*), etc.
The idea isn't just to get smaller patches, but to get patches that go
logically together (but still *do* something :) )
Thanks,
Nish
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
ckrm-tech mailing list
https://lists.sourceforge.net/lists/listinfo/ckrm-tech
