From: Wanpeng Li <[email protected]>
Signed-off-by: Wanpeng Li <[email protected]>
---
mm/vmscan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 2fc16cf..375d073 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -2539,7 +2539,7 @@ loop_again:
* consider it to be no longer congested. It's
* possible there are dirty pages backed by
* congested BDIs but as pressure is relieved,
- * spectulatively avoid congestion waits
+ * speculatively avoid congestion waits
*/
zone_clear_flag(zone, ZONE_CONGESTED);
if (i <= *classzone_idx)
--
1.7.9.5
On Sun, 17 Jun 2012, Wanpeng Li wrote:
> From: Wanpeng Li <[email protected]>
>
> Signed-off-by: Wanpeng Li <[email protected]>
I think it would be better to do per-subsystem audits like this in a
single patch, i.e. one patch for mm/*, one patch for net/*, etc, get it
acked, and then ask for it to be merged after an -rc1 release to avoid
lots of conflicts with other people's work.
On Sat, Jun 16, 2012 at 06:53:02PM -0700, David Rientjes wrote:
>On Sun, 17 Jun 2012, Wanpeng Li wrote:
>
>> From: Wanpeng Li <[email protected]>
>>
>> Signed-off-by: Wanpeng Li <[email protected]>
>
>I think it would be better to do per-subsystem audits like this in a
>single patch, i.e. one patch for mm/*, one patch for net/*, etc, get it
thank you David
>acked, and then ask for it to be merged after an -rc1 release to avoid
>lots of conflicts with other people's work.
You mean trivial maintainer only pull trivial patches for -rc1 release ?
Regards,
Wanpeng Li
On Sun, 17 Jun 2012, Wanpeng Li wrote:
> >acked, and then ask for it to be merged after an -rc1 release to avoid
> >lots of conflicts with other people's work.
>
> You mean trivial maintainer only pull trivial patches for -rc1 release ?
>
It all depends on how big your patch turns out to be; if it's sufficiently
large then it would probably be best to wait for -rc1, rebase your patch
to it, carry any acks that you have received, and ask it to be merged for
-rc2 to reduce conflicts with other code being pushed during the merge
window. Otherwise, just make a big patch and ask Andrew to carry it in
the -mm tree but make sure to base it off linux-next as it sits today.
You'll want to clone
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
On Sat, Jun 16, 2012 at 07:11:09PM -0700, David Rientjes wrote:
>On Sun, 17 Jun 2012, Wanpeng Li wrote:
>
>> >acked, and then ask for it to be merged after an -rc1 release to avoid
>> >lots of conflicts with other people's work.
>>
>> You mean trivial maintainer only pull trivial patches for -rc1 release ?
>>
>
>It all depends on how big your patch turns out to be; if it's sufficiently
>large then it would probably be best to wait for -rc1, rebase your patch
>to it, carry any acks that you have received, and ask it to be merged for
>-rc2 to reduce conflicts with other code being pushed during the merge
>window. Otherwise, just make a big patch and ask Andrew to carry it in
>the -mm tree but make sure to base it off linux-next as it sits today.
>You'll want to clone
>git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
Thank you David, thanks for your quick response.
Best Regards,
Wanpeng Li