#Diffmerge linux manual#
#Diffmerge linux code#
#Diffmerge linux series#

#Diffmerge linux code#

+ * Returns >= nr_cpu_ids if no further cpus set in both.Update: As of Visual Studio Code 1.70 Three-way merge with improvements were added. return will be > * the first cpumask pointer + * the cpu prior to the place to search (ie. + * cpumask_next_and - get the next cpu in *src1p & *src2p int _pure cpumask_any_but(const struct cpumask *mask, unsigned int cpu) int _pure cpumask_next_and(int n, const struct cpumask *, const struct cpumask *) Return find_next_zero_bit(cpumask_bits(srcp), nr_cpumask_bits, n+1) > e32bd0390739 ('lib/cpumask: move one-line wrappers around find_bit to the header') 7:07 ` Sander Vanheule 0 siblings, 1 reply 5+ messages in threadįrom: Stephen Rothwell 7:26 UTC ( / raw)Ĭc: Linux Kernel Mailing List, Linux Next Mailing List, Sander Vanheule 6:58 Stephen Rothwell 7:26 ` Stephen Rothwell

#Diffmerge linux series#

Them being run as one series if that would make things easier. If further merge conflicts arise with Yury's cpumask patches, I'm also fine with Think my patches should require too many changes anymore. The end result for the series should be the same though, and I don't Thanks for solving the conflicts, looks fine to me. > with the maintainer of the conflicting tree to minimise any particularly You may also want to consider cooperating > conflicts should be mentioned to your upstream maintainer when your tree > is now fixed as far as linux-next is concerned, but any non trivial > I fixed it up (I hope, see below) and can carry the fix as necessary. > 2b0b9f2665b2 ('cpumask: Fix invalid uniprocessor mask assumption') > e32bd0390739 ('lib/cpumask: move one-line wrappers around find_bit to the > 50e413c31800 ('lib/cpumask: change return types to unsigned') > Today's linux-next merge of the mm tree got a conflict in: On Mon, at 17:26 +1000, Stephen Rothwell wrote: To: Stephen Rothwell, Andrew Morton, Yury NorovĬc: Linux Kernel Mailing List, Linux Next Mailing List 7:26 ` Stephen Rothwell 7:07 ` Sander Vanheule 0 siblings, 0 replies 5+ messages in threadįrom: Sander Vanheule 7:07 UTC ( / raw)

#Diffmerge linux manual#

* Re: linux-next: manual merge of the mm tree with the bitmap tree #define GFP_KERNEL_ACCOUNT (GFP_KERNEL | _GFP_ACCOUNT) #define GFP_KERNEL (_GFP_RECLAIM | _GFP_IO | _GFP_FS) +#define GFP_ATOMIC (_GFP_HIGH|_GFP_KSWAPD_RECLAIM) #define GFP_ATOMIC (_GFP_HIGH|_GFP_ATOMIC|_GFP_KSWAPD_RECLAIM) * in page fault path, while the non-light is used by khugepaged. * version does not attempt reclaim/compaction at all and is by default used #define _GFP_NOMEMALLOC ((_force -329,7 +325,7 typedef unsigned int _bitwise gfp_t #define _GFP_MEMALLOC ((_force gfp_t)_GFP_MEMALLOC) #define _GFP_HIGH ((_force gfp_t)_GFP_HIGH) #define _GFP_ATOMIC ((_force gfp_t)_GFP_ATOMIC) * This takes precedence over the %_GFP_MEMALLOC flag if both are set. * %_GFP_NOMEMALLOC is used to explicitly forbid access to emergency reserves. * the caller guarantees the allocation will allow more memory to be -135,7 +132,6 typedef unsigned int _bitwise gfp_t * %_GFP_MEMALLOC allows access to all memory. + * For example creating an IO context to clean pages and requests

* %_GFP_ATOMIC indicates that the caller cannot reclaim or sleep and is * For example, creating an IO context to clean pages. * the request is necessary before the system can make forward progress. * %_GFP_HIGH indicates that the caller is high-priority and that granting #define _GFP_WRITE -116,11 +116,8 typedef unsigned int _bitwise gfp_t +++ -31,7 +31,7 typedef unsigned int _bitwise gfp_t Include/linux/gfp_types.h | 12 ++++-ġ file changed, 4 insertions(+), 8 deletions(-)ĭiff -git a/include/linux/gfp_types.h b/include/linux/gfp_types.h Interacting with 'mm: discard _GFP_ATOMIC' Subject: fix up for 'headers/deps: mm: Split out You may also want to considerĬooperating with the maintainer of the conflicting tree to minimise anyįrom 40347cfa3f5fe59fbf04be561c669f0dda06ea35 Mon Sep 17 00:00:00 2001 Non trivial conflicts should be mentioned to your upstream maintainer This is now fixed as far as linux-next is concerned, but any I fixed it up (I used the former version of this file and thenĪpplied the following merge resolution patch) and can carry the fix as Today's linux-next merge of the mm tree got a conflict in:ģ4973181c728 ('headers/deps: mm: Split out of ')Ĭ2cda11cec4f ('mm: discard _GFP_ATOMIC') Linux-next: manual merge of the mm tree with the bitmap tree All of help / color / mirror / Atom feed * linux-next: manual merge of the mm tree with the bitmap tree 11:14 Stephen Rothwell 0 siblings, 0 replies 5+ messages in threadįrom: Stephen Rothwell 11:14 UTC ( / raw)Ĭc: Ingo Molnar, Linux Kernel Mailing List, Linux Next Mailing List,