[PATCH v4 3/7] powerpc: use task_pid_nr() for TID allocation
From: Alastair D'Silva
The current implementation of TID allocation, using a global IDR, may
result in an errant process starving the system of available TIDs.
Instead, use task_pid_nr(), as mentioned by the original author. The
scenario described which prevented it's use is not applicable, as
set_thread_tidr can only be called after the task struct has been
populated.
In the unlikely event that 2 threads share the TID and are waiting,
all potential outcomes have been determined safe.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/switch_to.h | 1 -
arch/powerpc/kernel/process.c| 122 ---
2 files changed, 28 insertions(+), 95 deletions(-)
diff --git a/arch/powerpc/include/asm/switch_to.h
b/arch/powerpc/include/asm/switch_to.h
index be8c9fa23983..5b03d8a82409 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -94,6 +94,5 @@ static inline void clear_task_ebb(struct task_struct *t)
extern int set_thread_uses_vas(void);
extern int set_thread_tidr(struct task_struct *t);
-extern void clear_thread_tidr(struct task_struct *t);
#endif /* _ASM_POWERPC_SWITCH_TO_H */
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3b00da47699b..c5b8e53acbae 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1496,103 +1496,41 @@ int set_thread_uses_vas(void)
}
#ifdef CONFIG_PPC64
-static DEFINE_SPINLOCK(vas_thread_id_lock);
-static DEFINE_IDA(vas_thread_ida);
-
-/*
- * We need to assign a unique thread id to each thread in a process.
+/**
+ * Assign a TIDR (thread ID) for task @t and set it in the thread
+ * structure. For now, we only support setting TIDR for 'current' task.
*
- * This thread id, referred to as TIDR, and separate from the Linux's tgid,
- * is intended to be used to direct an ASB_Notify from the hardware to the
- * thread, when a suitable event occurs in the system.
+ * Since the TID value is a truncated form of it PID, it is possible
+ * (but unlikely) for 2 threads to have the same TID. In the unlikely event
+ * that 2 threads share the same TID and are waiting, one of the following
+ * cases will happen:
*
- * One such event is a "paste" instruction in the context of Fast Thread
- * Wakeup (aka Core-to-core wake up in the Virtual Accelerator Switchboard
- * (VAS) in POWER9.
+ * 1. The correct thread is running, the wrong thread is not
+ * In this situation, the correct thread is woken and proceeds to pass it's
+ * condition check.
*
- * To get a unique TIDR per process we could simply reuse task_pid_nr() but
- * the problem is that task_pid_nr() is not yet available copy_thread() is
- * called. Fixing that would require changing more intrusive arch-neutral
- * code in code path in copy_process()?.
+ * 2. Neither threads are running
+ * In this situation, neither thread will be woken. When scheduled, the waiting
+ * threads will execute either a wait, which will return immediately, followed
+ * by a condition check, which will pass for the correct thread and fail
+ * for the wrong thread, or they will execute the condition check immediately.
*
- * Further, to assign unique TIDRs within each process, we need an atomic
- * field (or an IDR) in task_struct, which again intrudes into the arch-
- * neutral code. So try to assign globally unique TIDRs for now.
+ * 3. The wrong thread is running, the correct thread is not
+ * The wrong thread will be woken, but will fail it's condition check and
+ * re-execute wait. The correct thread, when scheduled, will execute either
+ * it's condition check (which will pass), or wait, which returns immediately
+ * when called the first time after the thread is scheduled, followed by it's
+ * condition check (which will pass).
*
- * NOTE: TIDR 0 indicates that the thread does not need a TIDR value.
- * For now, only threads that expect to be notified by the VAS
- * hardware need a TIDR value and we assign values > 0 for those.
- */
-#define MAX_THREAD_CONTEXT ((1 << 16) - 1)
-static int assign_thread_tidr(void)
-{
- int index;
- int err;
- unsigned long flags;
-
-again:
- if (!ida_pre_get(&vas_thread_ida, GFP_KERNEL))
- return -ENOMEM;
-
- spin_lock_irqsave(&vas_thread_id_lock, flags);
- err = ida_get_new_above(&vas_thread_ida, 1, &index);
- spin_unlock_irqrestore(&vas_thread_id_lock, flags);
-
- if (err == -EAGAIN)
- goto again;
- else if (err)
- return err;
-
- if (index > MAX_THREAD_CONTEXT) {
- spin_lock_irqsave(&vas_thread_id_lock, flags);
- ida_remove(&vas_thread_ida, index);
- spin_unlock_irqrestore(&vas_thread_id_lock, flags);
- return -ENOMEM;
- }
-
- return index;
-}
-
-static void free_thread_tidr(int id)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&vas_thread_id_lock, flags);
- i
[PATCH v4 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available
From: Alastair D'Silva
In order for a userspace AFU driver to call the POWER9 specific
OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually
make that call.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/file.c | 25 +
include/uapi/misc/ocxl.h | 4
2 files changed, 29 insertions(+)
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index eb409a469f21..33ae46ce0a8a 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -168,12 +168,32 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context
*ctx,
}
#endif
+
+static long afu_ioctl_get_features(struct ocxl_context *ctx,
+ struct ocxl_ioctl_features __user *uarg)
+{
+ struct ocxl_ioctl_features arg;
+
+ memset(&arg, 0, sizeof(arg));
+
+#ifdef CONFIG_PPC64
+ if (cpu_has_feature(CPU_FTR_P9_TIDR))
+ arg.flags[0] |= OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT;
+#endif
+
+ if (copy_to_user(uarg, &arg, sizeof(arg)))
+ return -EFAULT;
+
+ return 0;
+}
+
#define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" :
\
+ x == OCXL_IOCTL_GET_FEATURES ? "GET_FEATURES" : \
"UNKNOWN")
static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -239,6 +259,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
break;
#endif
+ case OCXL_IOCTL_GET_FEATURES:
+ rc = afu_ioctl_get_features(ctx,
+ (struct ocxl_ioctl_features __user *) args);
+ break;
+
default:
rc = -EINVAL;
}
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 8d2748e69c84..bb80f294b429 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -55,6 +55,9 @@ struct ocxl_ioctl_p9_wait {
__u64 reserved3[3];
};
+#define OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT 0x01
+struct ocxl_ioctl_features {
+ __u64 flags[4];
};
struct ocxl_ioctl_irq_fd {
@@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd {
#define OCXL_IOCTL_IRQ_SET_FD _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd)
#define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct
ocxl_ioctl_metadata)
#define OCXL_IOCTL_ENABLE_P9_WAIT _IOR(OCXL_MAGIC, 0x15, struct
ocxl_ioctl_p9_wait)
+#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct
ocxl_ioctl_platform)
#endif /* _UAPI_MISC_OCXL_H */
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 7/7] ocxl: Document new OCXL IOCTLs
From: Alastair D'Silva Signed-off-by: Alastair D'Silva --- Documentation/accelerators/ocxl.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst index ddcc58d01cfb..14cefc020e2d 100644 --- a/Documentation/accelerators/ocxl.rst +++ b/Documentation/accelerators/ocxl.rst @@ -157,6 +157,17 @@ OCXL_IOCTL_GET_METADATA: Obtains configuration information from the card, such at the size of MMIO areas, the AFU version, and the PASID for the current context. +OCXL_IOCTL_ENABLE_P9_WAIT: + + Allows the AFU to wake a userspace thread executing 'wait'. Returns + information to userspace to allow it to configure the AFU. Note that + this is only available on POWER9. + +OCXL_IOCTL_GET_FEATURES: + + Reports on which CPU features that affect OpenCAPI are usable from + userspace. + mmap -- 2.14.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 4/7] ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action
From: Alastair D'Silva
The function removes the process element from NPU cache.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/pnv-ocxl.h | 2 +-
arch/powerpc/platforms/powernv/ocxl.c | 4 ++--
drivers/misc/ocxl/link.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/pnv-ocxl.h
b/arch/powerpc/include/asm/pnv-ocxl.h
index f6945d3bc971..208b5503f4ed 100644
--- a/arch/powerpc/include/asm/pnv-ocxl.h
+++ b/arch/powerpc/include/asm/pnv-ocxl.h
@@ -28,7 +28,7 @@ extern int pnv_ocxl_map_xsl_regs(struct pci_dev *dev, void
__iomem **dsisr,
extern int pnv_ocxl_spa_setup(struct pci_dev *dev, void *spa_mem, int PE_mask,
void **platform_data);
extern void pnv_ocxl_spa_release(void *platform_data);
-extern int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle);
+extern int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int
pe_handle);
extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr);
extern void pnv_ocxl_free_xive_irq(u32 irq);
diff --git a/arch/powerpc/platforms/powernv/ocxl.c
b/arch/powerpc/platforms/powernv/ocxl.c
index fa9b53af3c7b..8c65aacda9c8 100644
--- a/arch/powerpc/platforms/powernv/ocxl.c
+++ b/arch/powerpc/platforms/powernv/ocxl.c
@@ -475,7 +475,7 @@ void pnv_ocxl_spa_release(void *platform_data)
}
EXPORT_SYMBOL_GPL(pnv_ocxl_spa_release);
-int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle)
+int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle)
{
struct spa_data *data = (struct spa_data *) platform_data;
int rc;
@@ -483,7 +483,7 @@ int pnv_ocxl_spa_remove_pe(void *platform_data, int
pe_handle)
rc = opal_npu_spa_clear_cache(data->phb_opal_id, data->bdfn, pe_handle);
return rc;
}
-EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe);
+EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe_from_cache);
int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr)
{
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index f30790582dc0..656e8610eec2 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -599,7 +599,7 @@ int ocxl_link_remove_pe(void *link_handle, int pasid)
* On powerpc, the entry needs to be cleared from the context
* cache of the NPU.
*/
- rc = pnv_ocxl_spa_remove_pe(link->platform_data, pe_handle);
+ rc = pnv_ocxl_spa_remove_pe_from_cache(link->platform_data, pe_handle);
WARN_ON(rc);
pe_data = radix_tree_delete(&spa->pe_tree, pe_handle);
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 5/7] ocxl: Expose the thread_id needed for wait on POWER9
From: Alastair D'Silva
In order to successfully issue as_notify, an AFU needs to know the TID
to notify, which in turn means that this information should be
available in userspace so it can be communicated to the AFU.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/context.c | 5 +++-
drivers/misc/ocxl/file.c | 53 +++
drivers/misc/ocxl/link.c | 36 ++
drivers/misc/ocxl/ocxl_internal.h | 1 +
include/misc/ocxl.h | 9 +++
include/uapi/misc/ocxl.h | 10
6 files changed, 113 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
index 909e8807824a..95f74623113e 100644
--- a/drivers/misc/ocxl/context.c
+++ b/drivers/misc/ocxl/context.c
@@ -34,6 +34,8 @@ int ocxl_context_init(struct ocxl_context *ctx, struct
ocxl_afu *afu,
mutex_init(&ctx->xsl_error_lock);
mutex_init(&ctx->irq_lock);
idr_init(&ctx->irq_idr);
+ ctx->tidr = 0;
+
/*
* Keep a reference on the AFU to make sure it's valid for the
* duration of the life of the context
@@ -65,6 +67,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr)
{
int rc;
+ // Locks both status & tidr
mutex_lock(&ctx->status_mutex);
if (ctx->status != OPENED) {
rc = -EIO;
@@ -72,7 +75,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr)
}
rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid,
- current->mm->context.id, 0, amr, current->mm,
+ current->mm->context.id, ctx->tidr, amr, current->mm,
xsl_fault_error, ctx);
if (rc)
goto out;
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 038509e5d031..eb409a469f21 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -5,6 +5,8 @@
#include
#include
#include
+#include
+#include
#include "ocxl_internal.h"
@@ -123,11 +125,55 @@ static long afu_ioctl_get_metadata(struct ocxl_context
*ctx,
return 0;
}
+#ifdef CONFIG_PPC64
+static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
+ struct ocxl_ioctl_p9_wait __user *uarg)
+{
+ struct ocxl_ioctl_p9_wait arg;
+
+ memset(&arg, 0, sizeof(arg));
+
+ if (cpu_has_feature(CPU_FTR_P9_TIDR)) {
+ enum ocxl_context_status status;
+
+ // Locks both status & tidr
+ mutex_lock(&ctx->status_mutex);
+ if (!ctx->tidr) {
+ if (set_thread_tidr(current))
+ return -ENOENT;
+
+ ctx->tidr = current->thread.tidr;
+ }
+
+ status = ctx->status;
+ mutex_unlock(&ctx->status_mutex);
+
+ if (status == ATTACHED) {
+ int rc;
+ struct link *link = ctx->afu->fn->link;
+
+ rc = ocxl_link_update_pe(link, ctx->pasid, ctx->tidr);
+ if (rc)
+ return rc;
+ }
+
+ arg.thread_id = ctx->tidr;
+ } else
+ return -ENOENT;
+
+ if (copy_to_user(uarg, &arg, sizeof(arg)))
+ return -EFAULT;
+
+ return 0;
+}
+#endif
+
#define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
+ x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" :
\
"UNKNOWN")
static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -186,6 +232,13 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
(struct ocxl_ioctl_metadata __user *) args);
break;
+#ifdef CONFIG_PPC64
+ case OCXL_IOCTL_ENABLE_P9_WAIT:
+ rc = afu_ioctl_enable_p9_wait(ctx,
+ (struct ocxl_ioctl_p9_wait __user *) args);
+ break;
+#endif
+
default:
rc = -EINVAL;
}
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 656e8610eec2..88876ae8f330 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -544,6 +544,42 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32
pidr, u32 tidr,
}
EXPORT_SYMBOL_GPL(ocxl_link_add_pe);
+int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid)
+{
+ struct link *link = (struct link *) link_handle;
+ struct spa *spa = link->spa;
+ struct ocxl_process_element *pe;
+ int pe_handle, rc;
+
+ if (pasid > SPA
[PATCH v4 2/7] powerpc: Use TIDR CPU feature to control TIDR allocation
From: Alastair D'Silva
Switch the use of TIDR on it's CPU feature, rather than assuming it
is available based on architecture.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/kernel/process.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 1237f13fed51..3b00da47699b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1154,7 +1154,7 @@ static inline void restore_sprs(struct thread_struct
*old_thread,
mtspr(SPRN_TAR, new_thread->tar);
}
- if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ if (cpu_has_feature(CPU_FTR_P9_TIDR) &&
old_thread->tidr != new_thread->tidr)
mtspr(SPRN_TIDR, new_thread->tidr);
#endif
@@ -1570,7 +1570,7 @@ void clear_thread_tidr(struct task_struct *t)
if (!t->thread.tidr)
return;
- if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+ if (!cpu_has_feature(CPU_FTR_P9_TIDR)) {
WARN_ON_ONCE(1);
return;
}
@@ -1593,7 +1593,7 @@ int set_thread_tidr(struct task_struct *t)
{
int rc;
- if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ if (!cpu_has_feature(CPU_FTR_P9_TIDR))
return -EINVAL;
if (t != current)
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 0/7] ocxl: Implement Power9 as_notify/wait for OpenCAPI
From: Alastair D'Silva The Power 9 as_notify/wait feature provides a lower latency way to signal a thread that work is complete. This series enables the use of this feature from OpenCAPI adapters, as well as addressing a potential starvation issue when allocating thread IDs. Changelog: v4: Remove the "unique" statement from the set_thread_tidr function and move the text explaining why it is safe from the commit message to the function description v3: Fix references to POWER9 Remove stray whitespace edit from docs Add more details to commit message for "use task_pid_nr()" Retitle patch 6 to indicate OCXL rather than CPU features v2: Rename get_platform IOCTL to get_features Move stray edit from patch 1 to patch 3 Alastair D'Silva (7): powerpc: Add TIDR CPU feature for POWER9 powerpc: Use TIDR CPU feature to control TIDR allocation powerpc: use task_pid_nr() for TID allocation ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action ocxl: Expose the thread_id needed for wait on POWER9 ocxl: Add an IOCTL so userspace knows what OCXL features are available ocxl: Document new OCXL IOCTLs Documentation/accelerators/ocxl.rst | 11 arch/powerpc/include/asm/cputable.h | 3 +- arch/powerpc/include/asm/pnv-ocxl.h | 2 +- arch/powerpc/include/asm/switch_to.h | 1 - arch/powerpc/kernel/dt_cpu_ftrs.c | 1 + arch/powerpc/kernel/process.c | 101 +- arch/powerpc/platforms/powernv/ocxl.c | 4 +- drivers/misc/ocxl/context.c | 5 +- drivers/misc/ocxl/file.c | 78 ++ drivers/misc/ocxl/link.c | 38 - drivers/misc/ocxl/ocxl_internal.h | 1 + include/misc/ocxl.h | 9 +++ include/uapi/misc/ocxl.h | 14 + 13 files changed, 163 insertions(+), 105 deletions(-) -- 2.14.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v4 1/7] powerpc: Add TIDR CPU feature for POWER9
From: Alastair D'Silva
This patch adds a CPU feature bit to show whether the CPU has
the TIDR register available, enabling as_notify/wait in userspace.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/cputable.h | 3 ++-
arch/powerpc/kernel/dt_cpu_ftrs.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 4e332f3531c5..54c4cbbe57b4 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -215,6 +215,7 @@ static inline void cpu_feature_keys_init(void) { }
#define CPU_FTR_P9_TM_HV_ASSIST
LONG_ASM_CONST(0x1000)
#define CPU_FTR_P9_TM_XER_SO_BUG LONG_ASM_CONST(0x2000)
#define CPU_FTR_P9_TLBIE_BUG LONG_ASM_CONST(0x4000)
+#define CPU_FTR_P9_TIDR
LONG_ASM_CONST(0x8000)
#ifndef __ASSEMBLY__
@@ -462,7 +463,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
- CPU_FTR_P9_TLBIE_BUG)
+ CPU_FTR_P9_TLBIE_BUG | CPU_FTR_P9_TIDR)
#define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) & \
(~CPU_FTR_SAO))
#define CPU_FTRS_POWER9_DD2_0 CPU_FTRS_POWER9
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 11a3a4fed3fb..10f8b7f55637 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -722,6 +722,7 @@ static __init void cpufeatures_cpu_quirks(void)
if ((version & 0x) == 0x004e) {
cur_cpu_spec->cpu_features &= ~(CPU_FTR_DAWR);
cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_BUG;
+ cur_cpu_spec->cpu_features |= CPU_FTR_P9_TIDR;
}
}
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 3/7] powerpc: use task_pid_nr() for TID allocation
From: Alastair D'Silva
The current implementation of TID allocation, using a global IDR, may
result in an errant process starving the system of available TIDs.
Instead, use task_pid_nr(), as mentioned by the original author. The
scenario described which prevented it's use is not applicable, as
set_thread_tidr can only be called after the task struct has been
populated.
In the unlikely event that 2 threads share the TID and are waiting,
one of the following cases will happen:
1. The correct thread is running, the wrong thread is not
In this situation, the correct thread is woken and proceeds to pass it's
condition check.
2. Neither threads are running
In this situation, neither thread will be woken. When scheduled, the waiting
threads will execute either a wait, which will return immediately, followed
by a condition check, which will pass for the correct thread and fail
for the wrong thread, or they will execute the condition check immediately.
3. The wrong thread is running, the correct thread is not
The wrong thread will be woken, but will fail it's condition check and
re-execute wait. The correct thread, when scheduled, will execute either
it's condition check (which will pass), or wait, which returns immediately
when called the first time after the thread is scheduled, followed by it's
condition check (which will pass).
4. Both threads are running
Both threads will be woken. The wrong thread will fail it's condition check
and execute another wait, while the correct thread will pass it's condition
check.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/switch_to.h | 1 -
arch/powerpc/kernel/process.c| 97 +---
2 files changed, 1 insertion(+), 97 deletions(-)
diff --git a/arch/powerpc/include/asm/switch_to.h
b/arch/powerpc/include/asm/switch_to.h
index be8c9fa23983..5b03d8a82409 100644
--- a/arch/powerpc/include/asm/switch_to.h
+++ b/arch/powerpc/include/asm/switch_to.h
@@ -94,6 +94,5 @@ static inline void clear_task_ebb(struct task_struct *t)
extern int set_thread_uses_vas(void);
extern int set_thread_tidr(struct task_struct *t);
-extern void clear_thread_tidr(struct task_struct *t);
#endif /* _ASM_POWERPC_SWITCH_TO_H */
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 3b00da47699b..87f047fd2762 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1496,103 +1496,12 @@ int set_thread_uses_vas(void)
}
#ifdef CONFIG_PPC64
-static DEFINE_SPINLOCK(vas_thread_id_lock);
-static DEFINE_IDA(vas_thread_ida);
-
-/*
- * We need to assign a unique thread id to each thread in a process.
- *
- * This thread id, referred to as TIDR, and separate from the Linux's tgid,
- * is intended to be used to direct an ASB_Notify from the hardware to the
- * thread, when a suitable event occurs in the system.
- *
- * One such event is a "paste" instruction in the context of Fast Thread
- * Wakeup (aka Core-to-core wake up in the Virtual Accelerator Switchboard
- * (VAS) in POWER9.
- *
- * To get a unique TIDR per process we could simply reuse task_pid_nr() but
- * the problem is that task_pid_nr() is not yet available copy_thread() is
- * called. Fixing that would require changing more intrusive arch-neutral
- * code in code path in copy_process()?.
- *
- * Further, to assign unique TIDRs within each process, we need an atomic
- * field (or an IDR) in task_struct, which again intrudes into the arch-
- * neutral code. So try to assign globally unique TIDRs for now.
- *
- * NOTE: TIDR 0 indicates that the thread does not need a TIDR value.
- * For now, only threads that expect to be notified by the VAS
- * hardware need a TIDR value and we assign values > 0 for those.
- */
-#define MAX_THREAD_CONTEXT ((1 << 16) - 1)
-static int assign_thread_tidr(void)
-{
- int index;
- int err;
- unsigned long flags;
-
-again:
- if (!ida_pre_get(&vas_thread_ida, GFP_KERNEL))
- return -ENOMEM;
-
- spin_lock_irqsave(&vas_thread_id_lock, flags);
- err = ida_get_new_above(&vas_thread_ida, 1, &index);
- spin_unlock_irqrestore(&vas_thread_id_lock, flags);
-
- if (err == -EAGAIN)
- goto again;
- else if (err)
- return err;
-
- if (index > MAX_THREAD_CONTEXT) {
- spin_lock_irqsave(&vas_thread_id_lock, flags);
- ida_remove(&vas_thread_ida, index);
- spin_unlock_irqrestore(&vas_thread_id_lock, flags);
- return -ENOMEM;
- }
-
- return index;
-}
-
-static void free_thread_tidr(int id)
-{
- unsigned long flags;
-
- spin_lock_irqsave(&vas_thread_id_lock, flags);
- ida_remove(&vas_thread_ida, id);
- spin_unlock_irqrestore(&vas_thread_id_lock, flags);
-}
-
-/*
- * Clear any TIDR value assigned to this thread.
- */
-void clear_thread_tidr(struct task_struct *t)
-{
- if (!t->thread.tidr)
- return;
-
-
[PATCH v3 2/7] powerpc: Use TIDR CPU feature to control TIDR allocation
From: Alastair D'Silva
Switch the use of TIDR on it's CPU feature, rather than assuming it
is available based on architecture.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/kernel/process.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
index 1237f13fed51..3b00da47699b 100644
--- a/arch/powerpc/kernel/process.c
+++ b/arch/powerpc/kernel/process.c
@@ -1154,7 +1154,7 @@ static inline void restore_sprs(struct thread_struct
*old_thread,
mtspr(SPRN_TAR, new_thread->tar);
}
- if (cpu_has_feature(CPU_FTR_ARCH_300) &&
+ if (cpu_has_feature(CPU_FTR_P9_TIDR) &&
old_thread->tidr != new_thread->tidr)
mtspr(SPRN_TIDR, new_thread->tidr);
#endif
@@ -1570,7 +1570,7 @@ void clear_thread_tidr(struct task_struct *t)
if (!t->thread.tidr)
return;
- if (!cpu_has_feature(CPU_FTR_ARCH_300)) {
+ if (!cpu_has_feature(CPU_FTR_P9_TIDR)) {
WARN_ON_ONCE(1);
return;
}
@@ -1593,7 +1593,7 @@ int set_thread_tidr(struct task_struct *t)
{
int rc;
- if (!cpu_has_feature(CPU_FTR_ARCH_300))
+ if (!cpu_has_feature(CPU_FTR_P9_TIDR))
return -EINVAL;
if (t != current)
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 1/7] powerpc: Add TIDR CPU feature for POWER9
From: Alastair D'Silva
This patch adds a CPU feature bit to show whether the CPU has
the TIDR register available, enabling as_notify/wait in userspace.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/cputable.h | 3 ++-
arch/powerpc/kernel/dt_cpu_ftrs.c | 1 +
2 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/cputable.h
b/arch/powerpc/include/asm/cputable.h
index 4e332f3531c5..54c4cbbe57b4 100644
--- a/arch/powerpc/include/asm/cputable.h
+++ b/arch/powerpc/include/asm/cputable.h
@@ -215,6 +215,7 @@ static inline void cpu_feature_keys_init(void) { }
#define CPU_FTR_P9_TM_HV_ASSIST
LONG_ASM_CONST(0x1000)
#define CPU_FTR_P9_TM_XER_SO_BUG LONG_ASM_CONST(0x2000)
#define CPU_FTR_P9_TLBIE_BUG LONG_ASM_CONST(0x4000)
+#define CPU_FTR_P9_TIDR
LONG_ASM_CONST(0x8000)
#ifndef __ASSEMBLY__
@@ -462,7 +463,7 @@ static inline void cpu_feature_keys_init(void) { }
CPU_FTR_CFAR | CPU_FTR_HVMODE | CPU_FTR_VMX_COPY | \
CPU_FTR_DBELL | CPU_FTR_HAS_PPR | CPU_FTR_ARCH_207S | \
CPU_FTR_TM_COMP | CPU_FTR_ARCH_300 | CPU_FTR_PKEY | \
- CPU_FTR_P9_TLBIE_BUG)
+ CPU_FTR_P9_TLBIE_BUG | CPU_FTR_P9_TIDR)
#define CPU_FTRS_POWER9_DD1 ((CPU_FTRS_POWER9 | CPU_FTR_POWER9_DD1) & \
(~CPU_FTR_SAO))
#define CPU_FTRS_POWER9_DD2_0 CPU_FTRS_POWER9
diff --git a/arch/powerpc/kernel/dt_cpu_ftrs.c
b/arch/powerpc/kernel/dt_cpu_ftrs.c
index 11a3a4fed3fb..10f8b7f55637 100644
--- a/arch/powerpc/kernel/dt_cpu_ftrs.c
+++ b/arch/powerpc/kernel/dt_cpu_ftrs.c
@@ -722,6 +722,7 @@ static __init void cpufeatures_cpu_quirks(void)
if ((version & 0x) == 0x004e) {
cur_cpu_spec->cpu_features &= ~(CPU_FTR_DAWR);
cur_cpu_spec->cpu_features |= CPU_FTR_P9_TLBIE_BUG;
+ cur_cpu_spec->cpu_features |= CPU_FTR_P9_TIDR;
}
}
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 7/7] ocxl: Document new OCXL IOCTLs
From: Alastair D'Silva Signed-off-by: Alastair D'Silva --- Documentation/accelerators/ocxl.rst | 11 +++ 1 file changed, 11 insertions(+) diff --git a/Documentation/accelerators/ocxl.rst b/Documentation/accelerators/ocxl.rst index ddcc58d01cfb..14cefc020e2d 100644 --- a/Documentation/accelerators/ocxl.rst +++ b/Documentation/accelerators/ocxl.rst @@ -157,6 +157,17 @@ OCXL_IOCTL_GET_METADATA: Obtains configuration information from the card, such at the size of MMIO areas, the AFU version, and the PASID for the current context. +OCXL_IOCTL_ENABLE_P9_WAIT: + + Allows the AFU to wake a userspace thread executing 'wait'. Returns + information to userspace to allow it to configure the AFU. Note that + this is only available on POWER9. + +OCXL_IOCTL_GET_FEATURES: + + Reports on which CPU features that affect OpenCAPI are usable from + userspace. + mmap -- 2.14.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 0/7] ocxl: Implement Power9 as_notify/wait for OpenCAPI
From: Alastair D'Silva The Power 9 as_notify/wait feature provides a lower latency way to signal a thread that work is complete. This series enables the use of this feature from OpenCAPI adapters, as well as addressing a potential starvation issue when allocating thread IDs. Changelog: v3: Fix references to POWER9 Remove stray whitespace edit from docs Add more details to commit message for "use task_pid_nr()" Retitle patch 6 to indicate OCXL rather than CPU features v2: Rename get_platform IOCTL to get_features Move stray edit from patch 1 to patch 3 Alastair D'Silva (7): powerpc: Add TIDR CPU feature for POWER9 powerpc: Use TIDR CPU feature to control TIDR allocation powerpc: use task_pid_nr() for TID allocation ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action ocxl: Expose the thread_id needed for wait on POWER9 ocxl: Add an IOCTL so userspace knows what OCXL features are available ocxl: Document new OCXL IOCTLs Documentation/accelerators/ocxl.rst | 11 arch/powerpc/include/asm/cputable.h | 3 +- arch/powerpc/include/asm/pnv-ocxl.h | 2 +- arch/powerpc/include/asm/switch_to.h | 1 - arch/powerpc/kernel/dt_cpu_ftrs.c | 1 + arch/powerpc/kernel/process.c | 101 +- arch/powerpc/platforms/powernv/ocxl.c | 4 +- drivers/misc/ocxl/context.c | 5 +- drivers/misc/ocxl/file.c | 78 ++ drivers/misc/ocxl/link.c | 38 - drivers/misc/ocxl/ocxl_internal.h | 1 + include/misc/ocxl.h | 9 +++ include/uapi/misc/ocxl.h | 14 + 13 files changed, 163 insertions(+), 105 deletions(-) -- 2.14.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 4/7] ocxl: Rename pnv_ocxl_spa_remove_pe to clarify it's action
From: Alastair D'Silva
The function removes the process element from NPU cache.
Signed-off-by: Alastair D'Silva
---
arch/powerpc/include/asm/pnv-ocxl.h | 2 +-
arch/powerpc/platforms/powernv/ocxl.c | 4 ++--
drivers/misc/ocxl/link.c | 2 +-
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/include/asm/pnv-ocxl.h
b/arch/powerpc/include/asm/pnv-ocxl.h
index f6945d3bc971..208b5503f4ed 100644
--- a/arch/powerpc/include/asm/pnv-ocxl.h
+++ b/arch/powerpc/include/asm/pnv-ocxl.h
@@ -28,7 +28,7 @@ extern int pnv_ocxl_map_xsl_regs(struct pci_dev *dev, void
__iomem **dsisr,
extern int pnv_ocxl_spa_setup(struct pci_dev *dev, void *spa_mem, int PE_mask,
void **platform_data);
extern void pnv_ocxl_spa_release(void *platform_data);
-extern int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle);
+extern int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int
pe_handle);
extern int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr);
extern void pnv_ocxl_free_xive_irq(u32 irq);
diff --git a/arch/powerpc/platforms/powernv/ocxl.c
b/arch/powerpc/platforms/powernv/ocxl.c
index fa9b53af3c7b..8c65aacda9c8 100644
--- a/arch/powerpc/platforms/powernv/ocxl.c
+++ b/arch/powerpc/platforms/powernv/ocxl.c
@@ -475,7 +475,7 @@ void pnv_ocxl_spa_release(void *platform_data)
}
EXPORT_SYMBOL_GPL(pnv_ocxl_spa_release);
-int pnv_ocxl_spa_remove_pe(void *platform_data, int pe_handle)
+int pnv_ocxl_spa_remove_pe_from_cache(void *platform_data, int pe_handle)
{
struct spa_data *data = (struct spa_data *) platform_data;
int rc;
@@ -483,7 +483,7 @@ int pnv_ocxl_spa_remove_pe(void *platform_data, int
pe_handle)
rc = opal_npu_spa_clear_cache(data->phb_opal_id, data->bdfn, pe_handle);
return rc;
}
-EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe);
+EXPORT_SYMBOL_GPL(pnv_ocxl_spa_remove_pe_from_cache);
int pnv_ocxl_alloc_xive_irq(u32 *irq, u64 *trigger_addr)
{
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index f30790582dc0..656e8610eec2 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -599,7 +599,7 @@ int ocxl_link_remove_pe(void *link_handle, int pasid)
* On powerpc, the entry needs to be cleared from the context
* cache of the NPU.
*/
- rc = pnv_ocxl_spa_remove_pe(link->platform_data, pe_handle);
+ rc = pnv_ocxl_spa_remove_pe_from_cache(link->platform_data, pe_handle);
WARN_ON(rc);
pe_data = radix_tree_delete(&spa->pe_tree, pe_handle);
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 6/7] ocxl: Add an IOCTL so userspace knows what OCXL features are available
From: Alastair D'Silva
In order for a userspace AFU driver to call the POWER9 specific
OCXL_IOCTL_ENABLE_P9_WAIT, it needs to verify that it can actually
make that call.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/file.c | 25 +
include/uapi/misc/ocxl.h | 4
2 files changed, 29 insertions(+)
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index eb409a469f21..33ae46ce0a8a 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -168,12 +168,32 @@ static long afu_ioctl_enable_p9_wait(struct ocxl_context
*ctx,
}
#endif
+
+static long afu_ioctl_get_features(struct ocxl_context *ctx,
+ struct ocxl_ioctl_features __user *uarg)
+{
+ struct ocxl_ioctl_features arg;
+
+ memset(&arg, 0, sizeof(arg));
+
+#ifdef CONFIG_PPC64
+ if (cpu_has_feature(CPU_FTR_P9_TIDR))
+ arg.flags[0] |= OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT;
+#endif
+
+ if (copy_to_user(uarg, &arg, sizeof(arg)))
+ return -EFAULT;
+
+ return 0;
+}
+
#define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" :
\
+ x == OCXL_IOCTL_GET_FEATURES ? "GET_FEATURES" : \
"UNKNOWN")
static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -239,6 +259,11 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
break;
#endif
+ case OCXL_IOCTL_GET_FEATURES:
+ rc = afu_ioctl_get_features(ctx,
+ (struct ocxl_ioctl_features __user *) args);
+ break;
+
default:
rc = -EINVAL;
}
diff --git a/include/uapi/misc/ocxl.h b/include/uapi/misc/ocxl.h
index 8d2748e69c84..bb80f294b429 100644
--- a/include/uapi/misc/ocxl.h
+++ b/include/uapi/misc/ocxl.h
@@ -55,6 +55,9 @@ struct ocxl_ioctl_p9_wait {
__u64 reserved3[3];
};
+#define OCXL_IOCTL_FEATURES_FLAGS0_P9_WAIT 0x01
+struct ocxl_ioctl_features {
+ __u64 flags[4];
};
struct ocxl_ioctl_irq_fd {
@@ -72,5 +75,6 @@ struct ocxl_ioctl_irq_fd {
#define OCXL_IOCTL_IRQ_SET_FD _IOW(OCXL_MAGIC, 0x13, struct ocxl_ioctl_irq_fd)
#define OCXL_IOCTL_GET_METADATA _IOR(OCXL_MAGIC, 0x14, struct
ocxl_ioctl_metadata)
#define OCXL_IOCTL_ENABLE_P9_WAIT _IOR(OCXL_MAGIC, 0x15, struct
ocxl_ioctl_p9_wait)
+#define OCXL_IOCTL_GET_FEATURES _IOR(OCXL_MAGIC, 0x16, struct
ocxl_ioctl_platform)
#endif /* _UAPI_MISC_OCXL_H */
--
2.14.3
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v3 5/7] ocxl: Expose the thread_id needed for wait on POWER9
From: Alastair D'Silva
In order to successfully issue as_notify, an AFU needs to know the TID
to notify, which in turn means that this information should be
available in userspace so it can be communicated to the AFU.
Signed-off-by: Alastair D'Silva
---
drivers/misc/ocxl/context.c | 5 +++-
drivers/misc/ocxl/file.c | 53 +++
drivers/misc/ocxl/link.c | 36 ++
drivers/misc/ocxl/ocxl_internal.h | 1 +
include/misc/ocxl.h | 9 +++
include/uapi/misc/ocxl.h | 10
6 files changed, 113 insertions(+), 1 deletion(-)
diff --git a/drivers/misc/ocxl/context.c b/drivers/misc/ocxl/context.c
index 909e8807824a..95f74623113e 100644
--- a/drivers/misc/ocxl/context.c
+++ b/drivers/misc/ocxl/context.c
@@ -34,6 +34,8 @@ int ocxl_context_init(struct ocxl_context *ctx, struct
ocxl_afu *afu,
mutex_init(&ctx->xsl_error_lock);
mutex_init(&ctx->irq_lock);
idr_init(&ctx->irq_idr);
+ ctx->tidr = 0;
+
/*
* Keep a reference on the AFU to make sure it's valid for the
* duration of the life of the context
@@ -65,6 +67,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr)
{
int rc;
+ // Locks both status & tidr
mutex_lock(&ctx->status_mutex);
if (ctx->status != OPENED) {
rc = -EIO;
@@ -72,7 +75,7 @@ int ocxl_context_attach(struct ocxl_context *ctx, u64 amr)
}
rc = ocxl_link_add_pe(ctx->afu->fn->link, ctx->pasid,
- current->mm->context.id, 0, amr, current->mm,
+ current->mm->context.id, ctx->tidr, amr, current->mm,
xsl_fault_error, ctx);
if (rc)
goto out;
diff --git a/drivers/misc/ocxl/file.c b/drivers/misc/ocxl/file.c
index 038509e5d031..eb409a469f21 100644
--- a/drivers/misc/ocxl/file.c
+++ b/drivers/misc/ocxl/file.c
@@ -5,6 +5,8 @@
#include
#include
#include
+#include
+#include
#include "ocxl_internal.h"
@@ -123,11 +125,55 @@ static long afu_ioctl_get_metadata(struct ocxl_context
*ctx,
return 0;
}
+#ifdef CONFIG_PPC64
+static long afu_ioctl_enable_p9_wait(struct ocxl_context *ctx,
+ struct ocxl_ioctl_p9_wait __user *uarg)
+{
+ struct ocxl_ioctl_p9_wait arg;
+
+ memset(&arg, 0, sizeof(arg));
+
+ if (cpu_has_feature(CPU_FTR_P9_TIDR)) {
+ enum ocxl_context_status status;
+
+ // Locks both status & tidr
+ mutex_lock(&ctx->status_mutex);
+ if (!ctx->tidr) {
+ if (set_thread_tidr(current))
+ return -ENOENT;
+
+ ctx->tidr = current->thread.tidr;
+ }
+
+ status = ctx->status;
+ mutex_unlock(&ctx->status_mutex);
+
+ if (status == ATTACHED) {
+ int rc;
+ struct link *link = ctx->afu->fn->link;
+
+ rc = ocxl_link_update_pe(link, ctx->pasid, ctx->tidr);
+ if (rc)
+ return rc;
+ }
+
+ arg.thread_id = ctx->tidr;
+ } else
+ return -ENOENT;
+
+ if (copy_to_user(uarg, &arg, sizeof(arg)))
+ return -EFAULT;
+
+ return 0;
+}
+#endif
+
#define CMD_STR(x) (x == OCXL_IOCTL_ATTACH ? "ATTACH" :
\
x == OCXL_IOCTL_IRQ_ALLOC ? "IRQ_ALLOC" : \
x == OCXL_IOCTL_IRQ_FREE ? "IRQ_FREE" : \
x == OCXL_IOCTL_IRQ_SET_FD ? "IRQ_SET_FD" : \
x == OCXL_IOCTL_GET_METADATA ? "GET_METADATA" : \
+ x == OCXL_IOCTL_ENABLE_P9_WAIT ? "ENABLE_P9_WAIT" :
\
"UNKNOWN")
static long afu_ioctl(struct file *file, unsigned int cmd,
@@ -186,6 +232,13 @@ static long afu_ioctl(struct file *file, unsigned int cmd,
(struct ocxl_ioctl_metadata __user *) args);
break;
+#ifdef CONFIG_PPC64
+ case OCXL_IOCTL_ENABLE_P9_WAIT:
+ rc = afu_ioctl_enable_p9_wait(ctx,
+ (struct ocxl_ioctl_p9_wait __user *) args);
+ break;
+#endif
+
default:
rc = -EINVAL;
}
diff --git a/drivers/misc/ocxl/link.c b/drivers/misc/ocxl/link.c
index 656e8610eec2..88876ae8f330 100644
--- a/drivers/misc/ocxl/link.c
+++ b/drivers/misc/ocxl/link.c
@@ -544,6 +544,42 @@ int ocxl_link_add_pe(void *link_handle, int pasid, u32
pidr, u32 tidr,
}
EXPORT_SYMBOL_GPL(ocxl_link_add_pe);
+int ocxl_link_update_pe(void *link_handle, int pasid, __u16 tid)
+{
+ struct link *link = (struct link *) link_handle;
+ struct spa *spa = link->spa;
+ struct ocxl_process_element *pe;
+ int pe_handle, rc;
+
+ if (pasid > SPA
Re: [PATCH] Documentation: refcount-vs-atomic: Update reference to LKMM doc.
On Fri, 4 May 2018 23:11:49 +0200 Andrea Parri wrote: > The LKMM project has moved to 'tools/memory-model/'. > > Signed-off-by: Andrea Parri Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
On Tue, May 08, 2018 at 03:28:51PM -0300, Mauro Carvalho Chehab wrote:
> Em Tue, 8 May 2018 15:05:07 -0300
> Mauro Carvalho Chehab escreveu:
>
> > Em Tue, 08 May 2018 17:40:56 +0300
> > Jani Nikula escreveu:
[...]
> > > Side note, there's scripts/documentation-file-ref-check to grep the
> > > kernel tree for things that look like file references to Documentation/*
> > > and complain if they don't exist.
> > >
> > > I get about 350+ hits with that, patches welcome! ;)
> >
> > This small script fixes a bunch of such errors:
> >
> > scripts/documentation-file-ref-check 2>broken_refs
> > for i in $(cat broken_refs|cut -d: -f 2|grep -v
> > devicetree|sort|uniq|grep \\.txt); do
> > rst=$(basename $i)
> > rst=${rst/.txt/.rst}
> > f=$(find . -name $rst)
> > f=${f#./}
> > if [ "$f" != "" ]; then
> > echo "Replacing $i to $f"
> > for j in $(git grep -l $i); do
> > sed "s@$i@$f@g" -i $j
> > done
> > fi
> > done
>
> It follows an improvement to the above script that shows also what
> it didn't find as a ReST file, and the ones that have common names
> with multiple matches.
>
> I guess we could integrate something like that at
> scripts/documentation-file-ref-check, in order to allow auto-correcting
> renamed .txt files.
FWIW, this would be more than welcome with me; thank you,
Andrea
>
> Regards,
> Mauro
>
>
> #!/bin/bash
>
> scripts/documentation-file-ref-check 2>broken_refs
> for i in $(cat broken_refs|cut -d: -f 2|grep -v devicetree|sort|uniq|grep
> \\.txt); do
> rst=$(basename $i)
> rst=${rst/.txt/.rst}
> f=$(find . -name $rst)
>
> if [ "$f" == "" ]; then
> echo "ERROR: Didn't find a .rst replacement for $i"
> elif [ "$(echo $f | grep ' ')" != "" ]; then
> echo "ERROR: Found multiple possible replacements for $i:"
> for j in $f; do
> echo "$j"
> done
> else
> echo "Replacing $i to $f"
> f=${f#./}
> for j in $(git grep -l $i); do
> sed "s@$i@$f@g" -i $j
> done
> fi
> done
>
>
> Thanks,
> Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation/admin-guide/pm/intel_pstate: fix Active Mode w/o HWP paragraph
On Tue, 2018-05-08 at 17:12 +0200, Juri Lelli wrote: > P-state selection algorithm (powersave or performance) is selected by > echoing the desired choice to scaling_governor sysfs attribute and > not > to scaling_cur_freq (as currently stated). > > Fix it. Thanks for the fix. > > Signed-off-by: Juri Lelli > Cc: Jonathan Corbet > Cc: "Rafael J. Wysocki" > Cc: Srinivas Pandruvada > Cc: linux-doc@vger.kernel.org > Cc: linux...@vger.kernel.org Reviewed-by: Srinivas Pandruvada > > --- > Documentation/admin-guide/pm/intel_pstate.rst | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/Documentation/admin-guide/pm/intel_pstate.rst > b/Documentation/admin-guide/pm/intel_pstate.rst > index d2b6fda3d67b..ab2fe0eda1d7 100644 > --- a/Documentation/admin-guide/pm/intel_pstate.rst > +++ b/Documentation/admin-guide/pm/intel_pstate.rst > @@ -145,7 +145,7 @@ feature enabled.] > > In this mode ``intel_pstate`` registers utilization update callbacks > with the > CPU scheduler in order to run a P-state selection algorithm, either > -``powersave`` or ``performance``, depending on the > ``scaling_cur_freq`` policy > +``powersave`` or ``performance``, depending on the > ``scaling_governor`` policy > setting in ``sysfs``. The current CPU frequency information to be > made > available from the ``scaling_cur_freq`` policy attribute in > ``sysfs`` is > periodically updated by those utilization update callbacks too. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
Em Tue, 08 May 2018 17:40:56 +0300
Jani Nikula escreveu:
> On Mon, 07 May 2018, Andrea Parri wrote:
> > On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
> >> The cachetlb.txt is already in ReST format. So, move it to the
> >> core-api guide, where it belongs.
> >>
> >> Signed-off-by: Mauro Carvalho Chehab
> >> ---
> >> Documentation/00-INDEX| 2 --
> >> Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0
> >> Documentation/core-api/index.rst | 1 +
> >> Documentation/memory-barriers.txt | 2 +-
> >> Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
> >> 5 files changed, 3 insertions(+), 4 deletions(-)
> >> rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
> >
> > I see a few "inline" references to the .txt file in -rc4 (see below):
> > I am not sure if you managed to update them too.
>
> Side note, there's scripts/documentation-file-ref-check to grep the
> kernel tree for things that look like file references to Documentation/*
> and complain if they don't exist.
>
> I get about 350+ hits with that, patches welcome! ;)
This small script fixes a bunch of such errors:
scripts/documentation-file-ref-check 2>broken_refs
for i in $(cat broken_refs|cut -d: -f 2|grep -v
devicetree|sort|uniq|grep \\.txt); do
rst=$(basename $i)
rst=${rst/.txt/.rst}
f=$(find . -name $rst)
f=${f#./}
if [ "$f" != "" ]; then
echo "Replacing $i to $f"
for j in $(git grep -l $i); do
sed "s@$i@$f@g" -i $j
done
fi
done
Thanks,
Mauro
[PATCH] docs: Fix some broken references
As we move stuff around, some doc references are broken. Fix some of
them via this script:
scripts/documentation-file-ref-check 2>broken_refs
for i in $(cat broken_refs|cut -d: -f 2|grep -v
devicetree|sort|uniq|grep \\.txt); do
rst=$(basename $i)
rst=${rst/.txt/.rst}
f=$(find . -name $rst)
f=${f#./}
if [ "$f" != "" ]; then
echo "Replacing $i to $f"
for j in $(git grep -l $i); do
sed "s@$i@$f@g" -i $j
done
fi
done
Signed-off-by: Mauro Carvalho Chehab
diff --git a/Documentation/admin-guide/kernel-parameters.txt
b/Documentation/admin-guide/kernel-parameters.txt
index 42f3e2884e7c..a7c4dfb573df 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -4259,7 +4259,7 @@
[FTRACE] Set and start specified trace events in order
to facilitate early boot debugging. The event-list is a
comma separated list of trace events to enable. See
- also Documentation/trace/events.txt
+ also Documentation/trace/events.rst
trace_options=[option-list]
[FTRACE] Enable or disable tracer options at boot.
@@ -4274,7 +4274,7 @@
trace_options=stacktrace
- See also Documentation/trace/ftrace.txt "trace options"
+ See also Documentation/trace/ftrace.rst "trace options"
section.
tp_printk[FTRACE]
diff --git a/Documentation/devicetree/bindings/input/rotary-encoder.txt
b/Documentation/devicetree/bindings/input/rotary-encoder.txt
index f99fe5cdeaec..a644408b33b8 100644
--- a/Documentation/devicetree/bindings/input/rotary-encoder.txt
+++ b/Documentation/devicetree/bindings/input/rotary-encoder.txt
@@ -28,7 +28,7 @@ Deprecated properties:
This property is deprecated. Instead, a 'steps-per-period ' value should
be used, such as "rotary-encoder,steps-per-period = <2>".
-See Documentation/input/rotary-encoder.txt for more information.
+See Documentation/input/devices/rotary-encoder.rst for more information.
Example:
diff --git a/Documentation/driver-api/gpio/consumer.rst
b/Documentation/driver-api/gpio/consumer.rst
index c71a50d85b50..aa03f389d41d 100644
--- a/Documentation/driver-api/gpio/consumer.rst
+++ b/Documentation/driver-api/gpio/consumer.rst
@@ -57,7 +57,7 @@ device that displays digits), an additional index argument
can be specified::
enum gpiod_flags flags)
For a more detailed description of the con_id parameter in the DeviceTree case
-see Documentation/gpio/board.txt
+see Documentation/driver-api/gpio/board.rst
The flags parameter is used to optionally specify a direction and initial value
for the GPIO. Values can be:
diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
index 22208bf2386d..cb3b0de83fc6 100644
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
Em Tue, 8 May 2018 15:05:07 -0300
Mauro Carvalho Chehab escreveu:
> Em Tue, 08 May 2018 17:40:56 +0300
> Jani Nikula escreveu:
>
> > On Mon, 07 May 2018, Andrea Parri
> > wrote:
> > > On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
> > >> The cachetlb.txt is already in ReST format. So, move it to the
> > >> core-api guide, where it belongs.
> > >>
> > >> Signed-off-by: Mauro Carvalho Chehab
> > >> ---
> > >> Documentation/00-INDEX| 2 --
> > >> Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0
> > >> Documentation/core-api/index.rst | 1 +
> > >> Documentation/memory-barriers.txt | 2 +-
> > >> Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
> > >> 5 files changed, 3 insertions(+), 4 deletions(-)
> > >> rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
> > >
> > > I see a few "inline" references to the .txt file in -rc4 (see below):
> > > I am not sure if you managed to update them too.
> >
> > Side note, there's scripts/documentation-file-ref-check to grep the
> > kernel tree for things that look like file references to Documentation/*
> > and complain if they don't exist.
> >
> > I get about 350+ hits with that, patches welcome! ;)
>
> This small script fixes a bunch of such errors:
>
> scripts/documentation-file-ref-check 2>broken_refs
> for i in $(cat broken_refs|cut -d: -f 2|grep -v
> devicetree|sort|uniq|grep \\.txt); do
> rst=$(basename $i)
> rst=${rst/.txt/.rst}
> f=$(find . -name $rst)
> f=${f#./}
> if [ "$f" != "" ]; then
> echo "Replacing $i to $f"
> for j in $(git grep -l $i); do
> sed "s@$i@$f@g" -i $j
> done
> fi
> done
It follows an improvement to the above script that shows also what
it didn't find as a ReST file, and the ones that have common names
with multiple matches.
I guess we could integrate something like that at
scripts/documentation-file-ref-check, in order to allow auto-correcting
renamed .txt files.
Regards,
Mauro
#!/bin/bash
scripts/documentation-file-ref-check 2>broken_refs
for i in $(cat broken_refs|cut -d: -f 2|grep -v devicetree|sort|uniq|grep
\\.txt); do
rst=$(basename $i)
rst=${rst/.txt/.rst}
f=$(find . -name $rst)
if [ "$f" == "" ]; then
echo "ERROR: Didn't find a .rst replacement for $i"
elif [ "$(echo $f | grep ' ')" != "" ]; then
echo "ERROR: Found multiple possible replacements for $i:"
for j in $f; do
echo "$j"
done
else
echo "Replacing $i to $f"
f=${f#./}
for j in $(git grep -l $i); do
sed "s@$i@$f@g" -i $j
done
fi
done
Thanks,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [keyutils PATCH v2] man: keyctl_read(3): fix documentation for short buffer case
On Tue, Feb 20, 2018 at 11:42:34AM -0800, Eric Biggers wrote: > On Thu, Nov 02, 2017 at 11:06:05AM -0700, Eric Biggers wrote: > > From: Eric Biggers > > > > When keyctl_read() is passed a buffer that is too small, the behavior is > > inconsistent. Some key types will fill as much of the buffer as > > possible, while others won't copy anything. Moreover, the in-kernel > > documentation contradicted the man page on this point. > > > > Update the man page to say that this point is unspecified. > > > > Signed-off-by: Eric Biggers > > --- > > man/keyctl_read.3 | 8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > diff --git a/man/keyctl_read.3 b/man/keyctl_read.3 > > index 25821ad..852bc05 100644 > > --- a/man/keyctl_read.3 > > +++ b/man/keyctl_read.3 > > @@ -33,8 +33,8 @@ permission on a key to be able to read it. > > and > > .I buflen > > specify the buffer into which the payload data will be placed. If the > > buffer > > -is too small, the full size of the payload will be returned and no copy > > will > > -take place. > > +is too small, then the full size of the payload will be returned, and the > > +contents of the buffer may be overwritten in some undefined way. > > .P > > .BR keyctl_read_alloc () > > is similar to > > @@ -62,8 +62,8 @@ though the byte-ordering is as appropriate for the kernel. > > On success > > .BR keyctl_read () > > returns the amount of data placed into the buffer. If the buffer was too > > -small, then the size of buffer required will be returned, but no data will > > be > > -transferred. > > +small, then the size of buffer required will be returned, and the contents > > of > > +the buffer may have been overwritten in some undefined way. > > .P > > On success > > .BR keyctl_read_alloc () > > -- > > 2.15.0.403.gc27cc4dac6-goog > > > > Ping. Ping. -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/18] Fix some build warnings/errors with Sphinx
On Tue, May 08, 2018 at 10:13:42AM -0600, Jonathan Corbet wrote: > On Mon, 7 May 2018 06:35:36 -0300 > Mauro Carvalho Chehab wrote: > > > I decided to give a try with Sphinx last stable version > > (1.17.4), and noticed several issues. The worse one was > > with the networking book: a non-standard footnote there > > with [*] instead of a number causes it to break PDF building. > > > > So, I took some spare time to address some warnings all over > > the tree, and moved a few text documents to a book. > > OK, I've applied the ones that seem to make sense for me to take now. > There's comments on the firmware one, I'll fold in the fixes for the firmware API which do apply to my queue. Luis -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
On Tue, May 08, 2018 at 10:04:08AM -0600, Jonathan Corbet wrote: > On Mon, 7 May 2018 06:35:41 -0300 > Mauro Carvalho Chehab wrote: > > > The cachetlb.txt is already in ReST format. So, move it to the > > core-api guide, where it belongs. > > > > Signed-off-by: Mauro Carvalho Chehab > > I think we could do a better job of this by integrating it with the > kerneldoc comments. Meanwhile, though, this is a step in the right > direction, so I've applied it, thanks. This depends on what you mean by "the right direction": IMO, breaking in-sources references and get_maintainer.pl does not qualify as such. Andrea > > jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
On Tue, May 08, 2018 at 06:02:42PM +0200, Andrea Parri wrote:
> Hi Jani,
>
> On Tue, May 08, 2018 at 05:40:56PM +0300, Jani Nikula wrote:
> > On Mon, 07 May 2018, Andrea Parri wrote:
> > > On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
> > >> The cachetlb.txt is already in ReST format. So, move it to the
> > >> core-api guide, where it belongs.
> > >>
> > >> Signed-off-by: Mauro Carvalho Chehab
> > >> ---
> > >> Documentation/00-INDEX| 2 --
> > >> Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0
> > >> Documentation/core-api/index.rst | 1 +
> > >> Documentation/memory-barriers.txt | 2 +-
> > >> Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
> > >> 5 files changed, 3 insertions(+), 4 deletions(-)
> > >> rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
> > >
> > > I see a few "inline" references to the .txt file in -rc4 (see below):
> > > I am not sure if you managed to update them too.
> >
> > Side note, there's scripts/documentation-file-ref-check to grep the
> > kernel tree for things that look like file references to Documentation/*
> > and complain if they don't exist.
> >
> > I get about 350+ hits with that, patches welcome! ;)
>
> Thanks for pointing out the script/results.
>
> It's also worth stressing, I think, the fact that some of those are from
> the MAINTAINERS file; I stumbled accross one of them yesterday:
>
>
> http://lkml.kernel.org/r/1525707655-3542-1-git-send-email-andrea.pa...@amarulasolutions.com
>
> False positives apart (e.g., the four references in tools/memory-model/),
> those are regressions from my POV: please do not (consiously) merge more!
s/four/five
Andrea
>
> Andrea
>
>
> >
> >
> > BR,
> > Jani.
> >
> >
> > >
> > > ./arch/microblaze/include/asm/cacheflush.h:/* Look at
> > > Documentation/cachetlb.txt */
> > > ./arch/unicore32/include/asm/cacheflush.h: * See
> > > Documentation/cachetlb.txt for more information.
> > > ./arch/arm64/include/asm/cacheflush.h: * See Documentation/cachetlb.txt
> > > for more information. Please note that
> > > ./arch/arm/include/asm/cacheflush.h: *See Documentation/cachetlb.txt
> > > for more information.
> > > ./arch/xtensa/include/asm/cacheflush.h: * (see also
> > > Documentation/cachetlb.txt)
> > > ./arch/xtensa/include/asm/cacheflush.h:/* This is not required, see
> > > Documentation/cachetlb.txt */
> > >
> > > Andrea
> > >
> > >
> > >>
> > >> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
> > >> index 53699c79ee54..04074059bcdc 100644
> > >> --- a/Documentation/00-INDEX
> > >> +++ b/Documentation/00-INDEX
> > >> @@ -76,8 +76,6 @@ bus-devices/
> > >> - directory with info on TI GPMC (General Purpose Memory
> > >> Controller)
> > >> bus-virt-phys-mapping.txt
> > >> - how to access I/O mapped memory from within device drivers.
> > >> -cachetlb.txt
> > >> -- describes the cache/TLB flushing interfaces Linux uses.
> > >> cdrom/
> > >> - directory with information on the CD-ROM drivers that Linux
> > >> has.
> > >> cgroup-v1/
> > >> diff --git a/Documentation/cachetlb.txt
> > >> b/Documentation/core-api/cachetlb.rst
> > >> similarity index 100%
> > >> rename from Documentation/cachetlb.txt
> > >> rename to Documentation/core-api/cachetlb.rst
> > >> diff --git a/Documentation/core-api/index.rst
> > >> b/Documentation/core-api/index.rst
> > >> index c670a8031786..d4d71ee564ae 100644
> > >> --- a/Documentation/core-api/index.rst
> > >> +++ b/Documentation/core-api/index.rst
> > >> @@ -14,6 +14,7 @@ Core utilities
> > >> kernel-api
> > >> assoc_array
> > >> atomic_ops
> > >> + cachetlb
> > >> refcount-vs-atomic
> > >> cpu_hotplug
> > >> idr
> > >> diff --git a/Documentation/memory-barriers.txt
> > >> b/Documentation/memory-barriers.txt
> > >> index 6dafc8085acc..983249906fc6 100644
> > >> --- a/Documentation/memory-barriers.txt
> > >> +++ b/Documentation/memory-barriers.txt
> > >> @@ -2903,7 +2903,7 @@ is discarded from the CPU's cache and reloaded.
> > >> To deal with this, the
> > >> appropriate part of the kernel must invalidate the overlapping bits of
> > >> the
> > >> cache on each CPU.
> > >>
> > >> -See Documentation/cachetlb.txt for more information on cache management.
> > >> +See Documentation/core-api/cachetlb.rst for more information on cache
> > >> management.
> > >>
> > >>
> > >> CACHE COHERENCY VS MMIO
> > >> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
> > >> b/Documentation/translations/ko_KR/memory-barriers.txt
> > >> index 0a0930ab4156..081937577c1a 100644
> > >> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> > >> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> > >> @@ -2846,7 +2846,7 @@ CPU 의 캐시에서 RAM 으로 쓰여지는 더티 캐시 라인에 의해 덮
> > >> 문제를 해결하기 위해선, 커널의 적절한 부분에서 각 CPU 의 캐시 안의 문제가 되는
> > >> 비트들을 무효화 시켜야 합니다
Re: [PATCH 00/18] Fix some build warnings/errors with Sphinx
On Mon, 7 May 2018 06:35:36 -0300 Mauro Carvalho Chehab wrote: > I decided to give a try with Sphinx last stable version > (1.17.4), and noticed several issues. The worse one was > with the networking book: a non-standard footnote there > with [*] instead of a number causes it to break PDF building. > > So, I took some spare time to address some warnings all over > the tree, and moved a few text documents to a book. OK, I've applied the ones that seem to make sense for me to take now. There's comments on the firmware one, and I'd rather have Tejun's OK for the cgroup one. The code-comment changes should probably go via the usual maintainers. > I with > I had more time to move the other ones and to solve other > warnings. You and me both - but each step helps! Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 08/18] docs: driver-api: add clk documentation
On Mon, 7 May 2018 06:35:44 -0300 Mauro Carvalho Chehab wrote: > The clk.rst is already in ReST format. So, move it to the > driver-api guide, where it belongs. > > Signed-off-by: Mauro Carvalho Chehab Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 07/18] docs: core-api: add circular-buffers documentation
On Mon, 7 May 2018 06:35:43 -0300 Mauro Carvalho Chehab wrote: > The circular-buffers.txt is already in ReST format. So, move it to the > core-api guide, where it belongs. > > Signed-off-by: Mauro Carvalho Chehab Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
On Mon, 7 May 2018 06:35:41 -0300 Mauro Carvalho Chehab wrote: > The cachetlb.txt is already in ReST format. So, move it to the > core-api guide, where it belongs. > > Signed-off-by: Mauro Carvalho Chehab I think we could do a better job of this by integrating it with the kerneldoc comments. Meanwhile, though, this is a step in the right direction, so I've applied it, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
Hi Jani,
On Tue, May 08, 2018 at 05:40:56PM +0300, Jani Nikula wrote:
> On Mon, 07 May 2018, Andrea Parri wrote:
> > On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
> >> The cachetlb.txt is already in ReST format. So, move it to the
> >> core-api guide, where it belongs.
> >>
> >> Signed-off-by: Mauro Carvalho Chehab
> >> ---
> >> Documentation/00-INDEX| 2 --
> >> Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0
> >> Documentation/core-api/index.rst | 1 +
> >> Documentation/memory-barriers.txt | 2 +-
> >> Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
> >> 5 files changed, 3 insertions(+), 4 deletions(-)
> >> rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
> >
> > I see a few "inline" references to the .txt file in -rc4 (see below):
> > I am not sure if you managed to update them too.
>
> Side note, there's scripts/documentation-file-ref-check to grep the
> kernel tree for things that look like file references to Documentation/*
> and complain if they don't exist.
>
> I get about 350+ hits with that, patches welcome! ;)
Thanks for pointing out the script/results.
It's also worth stressing, I think, the fact that some of those are from
the MAINTAINERS file; I stumbled accross one of them yesterday:
http://lkml.kernel.org/r/1525707655-3542-1-git-send-email-andrea.pa...@amarulasolutions.com
False positives apart (e.g., the four references in tools/memory-model/),
those are regressions from my POV: please do not (consiously) merge more!
Andrea
>
>
> BR,
> Jani.
>
>
> >
> > ./arch/microblaze/include/asm/cacheflush.h:/* Look at
> > Documentation/cachetlb.txt */
> > ./arch/unicore32/include/asm/cacheflush.h: *See
> > Documentation/cachetlb.txt for more information.
> > ./arch/arm64/include/asm/cacheflush.h: *See Documentation/cachetlb.txt
> > for more information. Please note that
> > ./arch/arm/include/asm/cacheflush.h: * See Documentation/cachetlb.txt
> > for more information.
> > ./arch/xtensa/include/asm/cacheflush.h: * (see also
> > Documentation/cachetlb.txt)
> > ./arch/xtensa/include/asm/cacheflush.h:/* This is not required, see
> > Documentation/cachetlb.txt */
> >
> > Andrea
> >
> >
> >>
> >> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
> >> index 53699c79ee54..04074059bcdc 100644
> >> --- a/Documentation/00-INDEX
> >> +++ b/Documentation/00-INDEX
> >> @@ -76,8 +76,6 @@ bus-devices/
> >>- directory with info on TI GPMC (General Purpose Memory Controller)
> >> bus-virt-phys-mapping.txt
> >>- how to access I/O mapped memory from within device drivers.
> >> -cachetlb.txt
> >> - - describes the cache/TLB flushing interfaces Linux uses.
> >> cdrom/
> >>- directory with information on the CD-ROM drivers that Linux has.
> >> cgroup-v1/
> >> diff --git a/Documentation/cachetlb.txt
> >> b/Documentation/core-api/cachetlb.rst
> >> similarity index 100%
> >> rename from Documentation/cachetlb.txt
> >> rename to Documentation/core-api/cachetlb.rst
> >> diff --git a/Documentation/core-api/index.rst
> >> b/Documentation/core-api/index.rst
> >> index c670a8031786..d4d71ee564ae 100644
> >> --- a/Documentation/core-api/index.rst
> >> +++ b/Documentation/core-api/index.rst
> >> @@ -14,6 +14,7 @@ Core utilities
> >> kernel-api
> >> assoc_array
> >> atomic_ops
> >> + cachetlb
> >> refcount-vs-atomic
> >> cpu_hotplug
> >> idr
> >> diff --git a/Documentation/memory-barriers.txt
> >> b/Documentation/memory-barriers.txt
> >> index 6dafc8085acc..983249906fc6 100644
> >> --- a/Documentation/memory-barriers.txt
> >> +++ b/Documentation/memory-barriers.txt
> >> @@ -2903,7 +2903,7 @@ is discarded from the CPU's cache and reloaded. To
> >> deal with this, the
> >> appropriate part of the kernel must invalidate the overlapping bits of the
> >> cache on each CPU.
> >>
> >> -See Documentation/cachetlb.txt for more information on cache management.
> >> +See Documentation/core-api/cachetlb.rst for more information on cache
> >> management.
> >>
> >>
> >> CACHE COHERENCY VS MMIO
> >> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
> >> b/Documentation/translations/ko_KR/memory-barriers.txt
> >> index 0a0930ab4156..081937577c1a 100644
> >> --- a/Documentation/translations/ko_KR/memory-barriers.txt
> >> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
> >> @@ -2846,7 +2846,7 @@ CPU 의 캐시에서 RAM 으로 쓰여지는 더티 캐시 라인에 의해 덮
> >> 문제를 해결하기 위해선, 커널의 적절한 부분에서 각 CPU 의 캐시 안의 문제가 되는
> >> 비트들을 무효화 시켜야 합니다.
> >>
> >> -캐시 관리에 대한 더 많은 정보를 위해선 Documentation/cachetlb.txt 를
> >> +캐시 관리에 대한 더 많은 정보를 위해선 Documentation/core-api/cachetlb.rst 를
> >> 참고하세요.
> >>
> >>
> >> --
> >> 2.17.0
> >>
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> > the body of a message to majord...@vger.kernel.org
> > More majordomo info at http://vger.ker
Re: [PATCH 04/18] docs: admin-guide: add bcache documentation
On Mon, 7 May 2018 06:35:40 -0300 Mauro Carvalho Chehab wrote: > The bcache.txt is already in ReST format. So, move it to the > admin guide, where it belongs. > > Signed-off-by: Mauro Carvalho Chehab Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 03/18] docs: */index.rst: Add newer documents to their respective index.rst
On Mon, 7 May 2018 06:35:39 -0300 Mauro Carvalho Chehab wrote: > A number of new docs were added, but they're currently not on > the index.rst from the session they're supposed to be, causing > Sphinx warnings. > > Add them. > > Signed-off-by: Mauro Carvalho Chehab I've applied this one, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 06/18] docs: core-api: add cgroup-v2 documentation
On Mon, 7 May 2018 06:35:42 -0300 Mauro Carvalho Chehab wrote: > The cgroup-v2.txt is already in ReST format. So, move it to the > core-api guide, where it belongs. > > Signed-off-by: Mauro Carvalho Chehab Honestly, this seems to me like sysadmin material, so I think it should go into the admin guide instead. Actually, looking at the patch, it seems you agree - it's just the changelog that's wrong :) I could fix that, but it should probably be posted with a CC to Tejun first. Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 02/18] docs: fix location of request_firmware & friends
On Mon, May 07, 2018 at 06:35:38AM -0300, Mauro Carvalho Chehab wrote:
> commit 5d6d1ddd2730 ("firmware: move firmware loader into its own directory")
> and other commits renamed the old firmware_class.c file and split it
> into separate files, but documentation was not changed accordingly,
> causing Sphinx errors.
>
> Change the location accordingly at the documentation files.
>
> While here, add a missing entry at request_firmware.rst for
> release_firmware() function.
>
> Fixes: 5d6d1ddd2730 ("firmware: move firmware loader into its own directory")
> Cc: Kees Cook
> Cc: Luis R. Rodriguez
> Cc: Greg Kroah-Hartman
> Signed-off-by: Mauro Carvalho Chehab
> ---
> Documentation/dell_rbu.txt | 4 ++--
> .../driver-api/firmware/fallback-mechanisms.rst | 2 +-
> .../driver-api/firmware/request_firmware.rst| 17 +++--
> Documentation/driver-api/infrastructure.rst | 2 +-
> Documentation/power/suspend-and-cpuhotplug.txt | 2 +-
> 5 files changed, 16 insertions(+), 11 deletions(-)
>
> diff --git a/Documentation/dell_rbu.txt b/Documentation/dell_rbu.txt
> index 0fdb6aa2704c..befeff80e7ec 100644
> --- a/Documentation/dell_rbu.txt
> +++ b/Documentation/dell_rbu.txt
> @@ -121,8 +121,8 @@ read back the image downloaded.
>
> .. note::
>
> - This driver requires a patch for firmware_class.c which has the modified
> - request_firmware_nowait function.
> + This driver requires a patch for drivers/base/firmware_loader/main.c
> + which has the modified request_firmware_nowait() function.
>
> Also after updating the BIOS image a user mode application needs to
> execute
> code which sends the BIOS update request to the BIOS. So on the next
> reboot
This part looks good and is needed.
> diff --git a/Documentation/driver-api/firmware/fallback-mechanisms.rst
> b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> index f353783ae0be..7aed31b5a439 100644
> --- a/Documentation/driver-api/firmware/fallback-mechanisms.rst
> +++ b/Documentation/driver-api/firmware/fallback-mechanisms.rst
> @@ -72,7 +72,7 @@ the firmware requested, and establishes it in the device
> hierarchy by
> associating the device used to make the request as the device's parent.
> The sysfs directory's file attributes are defined and controlled through
> the new device's class (firmware_class) and group (fw_dev_attr_groups).
> -This is actually where the original firmware_class.c file name comes from,
> +This is actually where drivers/base/firmware_loader/fallback.c comes from,
Not this part.
What I meant to keep well documented here was not just only the old firmware
file name for the code, but also the module name firmware_class, and its
respective sysfs class name which is registered. From what I recall testing, we
could not rename the module now because of this. I believe it had to do with
the modular case, given the sysfs class could still be registered.
The fact that I forget the exact *issue* which prevented the module rename shows
how important it is to document this.
Folks 10 years from now may wonder why the hell that name stuck, and the point
was
to document that the *original* loader was the sysfs fallback mechanism.
> as originally the only firmware loading mechanism available was the
> mechanism we now use as a fallback mechanism.
>
> diff --git a/Documentation/driver-api/firmware/request_firmware.rst
> b/Documentation/driver-api/firmware/request_firmware.rst
> index cf4516dfbf96..8e34d29ea02d 100644
> --- a/Documentation/driver-api/firmware/request_firmware.rst
> +++ b/Documentation/driver-api/firmware/request_firmware.rst
> @@ -17,19 +17,24 @@ an error is returned.
>
> request_firmware
>
> -.. kernel-doc:: drivers/base/firmware_class.c
> +.. kernel-doc:: drivers/base/firmware_loader/main.c
> :functions: request_firmware
This is fixed on Hans de Goede's patch already merged on Greg's own tree.
> request_firmware_direct
> ---
> -.. kernel-doc:: drivers/base/firmware_class.c
> +.. kernel-doc:: drivers/base/firmware_loader/main.c
> :functions: request_firmware_direct
This is fixed on Hans de Goede's patch already merged on Greg's own tree.
> request_firmware_into_buf
> -
> -.. kernel-doc:: drivers/base/firmware_class.c
> +.. kernel-doc:: drivers/base/firmware_loader/main.c
> :functions: request_firmware_into_buf
This is fixed on Hans de Goede's patch already merged on Greg's own tree.
> +release_firmware
> +
> +.. kernel-doc:: drivers/base/firmware_loader/main.c
> + :functions: release_firmware
This is fixed on Hans de Goede's patch already merged on Greg's own tree.
> +
> Asynchronous firmware requests
> ==
>
> @@ -41,7 +46,7 @@ in atomic contexts.
>
> request_firmware_nowait
> ---
> -.. kernel-doc:: drivers/base/firmware_class.c
> +.. kernel-doc:: drivers/base/firmware_loader/main.c
>
Re: [PATCH 0/3] docs/vm: move numa_memory_policy.rst to admin-guide/mm
On Tue, 8 May 2018 10:02:07 +0300 Mike Rapoport wrote: > These patches include minor formatting and spelling updates to > Documentation/vm/numa_memory_policy.rst and move this file to > Documentation/admin-guide/mm. Set applied - thanks! jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: coresight: documentation: update sysfs section
On 7 May 2018 at 16:29, Kim Phillips wrote:
> - Align and show updated ls devices output from the TC2, based on
> current driver
>
> - Provide an example from an ETMv4 based system (Juno)
>
> - Reflect changes to the way the RAM write pointer is accessed since
> it got changed in commit 7d83d17795ef ("coresight: tmc: adding sysFS
> management entries").
>
> Cc: Mathieu Poirier
> Cc: Jonathan Corbet
> Signed-off-by: Kim Phillips
> ---
> Documentation/trace/coresight.txt | 40 ++-
> 1 file changed, 24 insertions(+), 16 deletions(-)
>
> diff --git a/Documentation/trace/coresight.txt
> b/Documentation/trace/coresight.txt
> index 6f0120c3a4f1..d23d6354b372 100644
> --- a/Documentation/trace/coresight.txt
> +++ b/Documentation/trace/coresight.txt
> @@ -144,10 +144,21 @@ If everything goes well during the registration process
> the new devices will
> show up under /sys/bus/coresight/devices, as showns here for a TC2 platform:
>
> root:~# ls /sys/bus/coresight/devices/
> -replicator 2003.tpiu2201c000.ptm 2203c000.etm 2203e000.etm
> -2001.etb 2004.funnel 2201d000.ptm 2203d000.etm
> +2001.etb 2004.funnel 2201d000.ptm 2203d000.etm replicator
> +2003.tpiu 2201c000.ptm2203c000.etm 2203e000.etm
> root:~#
>
> +and here for a Juno platform:
> +
> +root@juno:~# ls /sys/bus/coresight/devices/
> +2001.etf2012.replicator 2204.etm 230c.funnel
> +2003.tpiu 2013.funnel 220c.funnel 2314.etm
> +2004.funnel 2014.etf2214.etm 2324.etm
> +2007.etr2015.funnel 2304.etm 2334.etm
> +root@juno:~#
> +
> +Note the Juno uses an Embedded Trace Router (ETR) instead of an ETB.
The above is not entirely correct. On Juno users can select the ETF,
ETR and TPIU as a sink target while on TC2, the ETB and TPIU can be
selected.
> +
> The functions take a "struct coresight_device", which looks like this:
>
> struct coresight_desc {
> @@ -193,16 +204,16 @@ the information carried in "THIS_MODULE".
> How to use the tracer modules
> -
>
> -Before trace collection can start, a coresight sink needs to be identify.
> +Before trace collection can start, a coresight sink needs to be identified.
> There is no limit on the amount of sinks (nor sources) that can be enabled at
> any given moment. As a generic operation, all device pertaining to the sink
> class will have an "active" entry in sysfs:
>
> root:/sys/bus/coresight/devices# ls
> -replicator 2003.tpiu2201c000.ptm 2203c000.etm 2203e000.etm
> -2001.etb 2004.funnel 2201d000.ptm 2203d000.etm
> +2001.etb 2004.funnel 2201d000.ptm 2203d000.etm replicator
> +2003.tpiu 2201c000.ptm2203c000.etm 2203e000.etm
> root:/sys/bus/coresight/devices# ls 2001.etb
> -enable_sink status trigger_cntr
> +enable_sink mgmt power subsystem trigger_cntr uevent
> root:/sys/bus/coresight/devices# echo 1 > 2001.etb/enable_sink
> root:/sys/bus/coresight/devices# cat 2001.etb/enable_sink
> 1
> @@ -216,16 +227,13 @@ trigger a trace capture:
> root:/sys/bus/coresight/devices# echo 1 > 2201c000.ptm/enable_source
> root:/sys/bus/coresight/devices# cat 2201c000.ptm/enable_source
> 1
> -root:/sys/bus/coresight/devices# cat 2001.etb/status
> -Depth: 0x2000
> -Status: 0x1
> -RAM read ptr: 0x0
> -RAM wrt ptr:0x19d3 <- The write pointer is moving
> -Trigger cnt:0x0
> -Control:0x1
> -Flush status: 0x0
> -Flush ctrl: 0x2001
> -root:/sys/bus/coresight/devices#
> +
> +Observe the write pointer moving:
> +
> +root:/sys/bus/coresight/devices# cat 2001.etb/mgmt/rwp
> +0x1a8
> +root:/sys/bus/coresight/devices# cat 2001.etb/mgmt/rwp
> +0x19a6
>
> Trace collection is stopped the same way:
>
> --
> 2.17.0
>
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v3 0/6] Documentation/features: Provide and apply 'features-refresh.sh'
On Mon, 7 May 2018 12:43:37 +0200 Andrea Parri wrote: > This series provides the script 'features-refresh.sh', which operates on > the arch support status files, and it applies this script to refresh the > status files in place; previous discussions about this series are at [1]. Looks good, I've applied the set, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Documentation: block: cmdline-partition.txt fixes and additions
On Sun, 6 May 2018 11:50:29 -0700 Randy Dunlap wrote: > Make the description of the kernel command line option "blkdevparts" > a bit more flowing and readable. > > Fix a few typos. > Add the optional and suffixes. > Note that size can be "-" to indicate all of the remaining space. > > Signed-off-by: Randy Dunlap Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] vfio: fix documentation
On Mon, 7 May 2018 11:02:10 +0800 "dongbo (E)" wrote: > Update vfio_add_group_dev description to match the current API. > > Signed-off-by: Dong Bo Applied, thanks. jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] Documentation/admin-guide/pm/intel_pstate: fix Active Mode w/o HWP paragraph
P-state selection algorithm (powersave or performance) is selected by echoing the desired choice to scaling_governor sysfs attribute and not to scaling_cur_freq (as currently stated). Fix it. Signed-off-by: Juri Lelli Cc: Jonathan Corbet Cc: "Rafael J. Wysocki" Cc: Srinivas Pandruvada Cc: linux-doc@vger.kernel.org Cc: linux...@vger.kernel.org --- Documentation/admin-guide/pm/intel_pstate.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/admin-guide/pm/intel_pstate.rst b/Documentation/admin-guide/pm/intel_pstate.rst index d2b6fda3d67b..ab2fe0eda1d7 100644 --- a/Documentation/admin-guide/pm/intel_pstate.rst +++ b/Documentation/admin-guide/pm/intel_pstate.rst @@ -145,7 +145,7 @@ feature enabled.] In this mode ``intel_pstate`` registers utilization update callbacks with the CPU scheduler in order to run a P-state selection algorithm, either -``powersave`` or ``performance``, depending on the ``scaling_cur_freq`` policy +``powersave`` or ``performance``, depending on the ``scaling_governor`` policy setting in ``sysfs``. The current CPU frequency information to be made available from the ``scaling_cur_freq`` policy attribute in ``sysfs`` is periodically updated by those utilization update callbacks too. -- 2.14.3 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/6] mm, arm64: untag user addresses in mm/gup.c
On Wed, May 02, 2018 at 07:25:17PM +0200, Andrey Konovalov wrote: > On Wed, May 2, 2018 at 5:36 PM, Kirill A. Shutemov > wrote: > > On Wed, May 02, 2018 at 02:38:42PM +, Andrey Konovalov wrote: > >> > Does having a tagged address here makes any difference? I couldn't hit a > >> > failure with my simple tests (LD_PRELOAD a library that randomly adds > >> > tags to pointers returned by malloc). > >> > >> I think you're right, follow_page_mask is only called from > >> __get_user_pages, which already untagged the address. I'll remove > >> untagging here. > > > > It also called from follow_page(). Have you covered all its callers? > > Oh, missed that, will take a look. > > Thinking about that, would it make sense to add untagging to find_vma > (and others) instead of trying to cover all find_vma callers? I don't think adding the untagging to find_vma() is sufficient. In many cases the caller does a subsequent check like 'start < vma->vm_start' (see sys_msync() as an example, there are a few others as well). What I did in my tests was a WARN_ON_ONCE() in find_vma() if the address is tagged. -- Catalin -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] doc: botching-up-ioctls: Make it clearer why structs must be padded
On Wed, 2 May 2018 09:51:06 +0200 Daniel Vetter wrote: > This came up in discussions when reviewing drm patches. Applied, thanks. > Aside: I wonder whether we shouldn't move this to some other place and > rst-ify it? Any good suggestions? For the moment, probably in Documentation/process, next to volatile-considered-harmful.rst and such. Even better, of course, would be to have some nice document on designing user-space APIs in general... one can always dream ... :) Thanks, jon -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 05/18] docs: core-api: add cachetlb documentation
On Mon, 07 May 2018, Andrea Parri wrote:
> On Mon, May 07, 2018 at 06:35:41AM -0300, Mauro Carvalho Chehab wrote:
>> The cachetlb.txt is already in ReST format. So, move it to the
>> core-api guide, where it belongs.
>>
>> Signed-off-by: Mauro Carvalho Chehab
>> ---
>> Documentation/00-INDEX| 2 --
>> Documentation/{cachetlb.txt => core-api/cachetlb.rst} | 0
>> Documentation/core-api/index.rst | 1 +
>> Documentation/memory-barriers.txt | 2 +-
>> Documentation/translations/ko_KR/memory-barriers.txt | 2 +-
>> 5 files changed, 3 insertions(+), 4 deletions(-)
>> rename Documentation/{cachetlb.txt => core-api/cachetlb.rst} (100%)
>
> I see a few "inline" references to the .txt file in -rc4 (see below):
> I am not sure if you managed to update them too.
Side note, there's scripts/documentation-file-ref-check to grep the
kernel tree for things that look like file references to Documentation/*
and complain if they don't exist.
I get about 350+ hits with that, patches welcome! ;)
BR,
Jani.
>
> ./arch/microblaze/include/asm/cacheflush.h:/* Look at
> Documentation/cachetlb.txt */
> ./arch/unicore32/include/asm/cacheflush.h: * See Documentation/cachetlb.txt
> for more information.
> ./arch/arm64/include/asm/cacheflush.h: * See Documentation/cachetlb.txt
> for more information. Please note that
> ./arch/arm/include/asm/cacheflush.h: *See Documentation/cachetlb.txt
> for more information.
> ./arch/xtensa/include/asm/cacheflush.h: * (see also
> Documentation/cachetlb.txt)
> ./arch/xtensa/include/asm/cacheflush.h:/* This is not required, see
> Documentation/cachetlb.txt */
>
> Andrea
>
>
>>
>> diff --git a/Documentation/00-INDEX b/Documentation/00-INDEX
>> index 53699c79ee54..04074059bcdc 100644
>> --- a/Documentation/00-INDEX
>> +++ b/Documentation/00-INDEX
>> @@ -76,8 +76,6 @@ bus-devices/
>> - directory with info on TI GPMC (General Purpose Memory Controller)
>> bus-virt-phys-mapping.txt
>> - how to access I/O mapped memory from within device drivers.
>> -cachetlb.txt
>> -- describes the cache/TLB flushing interfaces Linux uses.
>> cdrom/
>> - directory with information on the CD-ROM drivers that Linux has.
>> cgroup-v1/
>> diff --git a/Documentation/cachetlb.txt b/Documentation/core-api/cachetlb.rst
>> similarity index 100%
>> rename from Documentation/cachetlb.txt
>> rename to Documentation/core-api/cachetlb.rst
>> diff --git a/Documentation/core-api/index.rst
>> b/Documentation/core-api/index.rst
>> index c670a8031786..d4d71ee564ae 100644
>> --- a/Documentation/core-api/index.rst
>> +++ b/Documentation/core-api/index.rst
>> @@ -14,6 +14,7 @@ Core utilities
>> kernel-api
>> assoc_array
>> atomic_ops
>> + cachetlb
>> refcount-vs-atomic
>> cpu_hotplug
>> idr
>> diff --git a/Documentation/memory-barriers.txt
>> b/Documentation/memory-barriers.txt
>> index 6dafc8085acc..983249906fc6 100644
>> --- a/Documentation/memory-barriers.txt
>> +++ b/Documentation/memory-barriers.txt
>> @@ -2903,7 +2903,7 @@ is discarded from the CPU's cache and reloaded. To
>> deal with this, the
>> appropriate part of the kernel must invalidate the overlapping bits of the
>> cache on each CPU.
>>
>> -See Documentation/cachetlb.txt for more information on cache management.
>> +See Documentation/core-api/cachetlb.rst for more information on cache
>> management.
>>
>>
>> CACHE COHERENCY VS MMIO
>> diff --git a/Documentation/translations/ko_KR/memory-barriers.txt
>> b/Documentation/translations/ko_KR/memory-barriers.txt
>> index 0a0930ab4156..081937577c1a 100644
>> --- a/Documentation/translations/ko_KR/memory-barriers.txt
>> +++ b/Documentation/translations/ko_KR/memory-barriers.txt
>> @@ -2846,7 +2846,7 @@ CPU 의 캐시에서 RAM 으로 쓰여지는 더티 캐시 라인에 의해 덮
>> 문제를 해결하기 위해선, 커널의 적절한 부분에서 각 CPU 의 캐시 안의 문제가 되는
>> 비트들을 무효화 시켜야 합니다.
>>
>> -캐시 관리에 대한 더 많은 정보를 위해선 Documentation/cachetlb.txt 를
>> +캐시 관리에 대한 더 많은 정보를 위해선 Documentation/core-api/cachetlb.rst 를
>> 참고하세요.
>>
>>
>> --
>> 2.17.0
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-doc" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
Jani Nikula, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 18/18] w1: w1_io.c: fix a kernel-doc warning
Hi 07.05.2018, 12:36, "Mauro Carvalho Chehab" : > Add a blank line to avoid this Sphinx warning: > ./drivers/w1/w1_io.c:197: WARNING: Definition list ends without a > blank line; unexpected unindent. > > Signed-off-by: Mauro Carvalho Chehab Looks good to me, thank you! What tree should this be forwarded to, or folks from linux doc will pick it up? Acked-by: Evgeniy Polyakov > --- > drivers/w1/w1_io.c | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/drivers/w1/w1_io.c b/drivers/w1/w1_io.c > index 075d120e7b88..0364d3329c52 100644 > --- a/drivers/w1/w1_io.c > +++ b/drivers/w1/w1_io.c > @@ -194,6 +194,7 @@ static u8 w1_read_bit(struct w1_master *dev) > * bit 0 = id_bit > * bit 1 = comp_bit > * bit 2 = dir_taken > + * > * If both bits 0 & 1 are set, the search should be restarted. > * > * Return: bit fields - see above > -- > 2.17.0 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)
Hi Masami,
On 05/07/2018 09:26 PM, Masami Hiramatsu wrote:
> On Mon, 7 May 2018 13:51:21 +0530
> Ravi Bangoria wrote:
>
>> Hi Masami,
>>
>> On 05/04/2018 07:51 PM, Ravi Bangoria wrote:
> +}
> +
> +static void sdt_increment_ref_ctr(struct trace_uprobe *tu)
> +{
> + struct uprobe_map_info *info;
> +
> + uprobe_down_write_dup_mmap();
> + info = uprobe_build_map_info(tu->inode->i_mapping,
> + tu->ref_ctr_offset, false);
> + if (IS_ERR(info))
> + goto out;
> +
> + while (info) {
> + down_write(&info->mm->mmap_sem);
> +
> + if (sdt_find_vma(tu, info->mm, info->vaddr))
> + sdt_update_ref_ctr(info->mm, info->vaddr, 1);
Don't you have to handle the error to map pages here?
>>> Correct.. I think, I've to feedback error code to
>>> probe_event_{enable|disable}
>>> and handler failure there.
>> I looked at this. Actually, It looks difficult to feedback errors to
>> probe_event_{enable|disable}, esp. in the mmap() case.
> Hmm, can't you roll that back if sdt_increment_ref_ctr() fails?
> If so, how does sdt_decrement_ref_ctr() work in that case?
Yes, it's easy to rollback in sdt_increment_ref_ctr(). But not much can
be done if trace_uprobe_mmap() fails.
What would be good is, if we can feedback uprobe_mmap() failures
to the perf infrastructure, which can finally be parsed by perf record.
But that should be done as a separate work.
>> Is it fine if we just warn sdt_update_ref_ctr() failures in dmesg? I'm
>> doing this in [PATCH 7]. (Though, it makes more sense to do that in
>> [PATCH 6], will change it in next version).
> Of course we need to warn it at least, but the best is rejecting to
> enable it.
Yes, we can reject it for sdt_increment_ref_ctr() failures.
>> Any better ideas?
>>
>> BTW, same issue exists for normal uprobe. If uprobe_mmap() fails,
>> there is no feedback to trace_uprobe and no warnigns in dmesg as
>> well !! There was a patch by Naveen to warn such failures in dmesg
>> but that didn't go in: https://lkml.org/lkml/2017/9/22/155
> Oops, that's a real bug. It seems the ball is in Naveen's hand.
> Naveen, could you update it according to Oleg's comment, and resend it?
>
>> Also, I'll add a check in sdt_update_ref_ctr() to make sure reference
>> counter never goes to negative incase increment fails but decrement
>> succeeds. OTOH, if increment succeeds but decrement fails, the
>> counter remains >0 but there is no harm as such, except we will
>> execute some unnecessary code.
> I see. Please carefully clarify whether such case is kernel's bug or not.
> I would like to know what the condition causes that uneven behavior.
Sure, will do that.
Thanks,
Ravi
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 6/9] trace_uprobe: Support SDT markers having reference count (semaphore)
Masami Hiramatsu wrote: On Mon, 7 May 2018 13:51:21 +0530 Ravi Bangoria wrote: BTW, same issue exists for normal uprobe. If uprobe_mmap() fails, there is no feedback to trace_uprobe and no warnigns in dmesg as well !! There was a patch by Naveen to warn such failures in dmesg but that didn't go in: https://lkml.org/lkml/2017/9/22/155 Oops, that's a real bug. It seems the ball is in Naveen's hand. Naveen, could you update it according to Oleg's comment, and resend it? Yes, I've had to put that series on the backburner. I will try and get to it soon. Thanks for the reminder. - Naveen -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 1/3] docs/vm: numa_memory_policy: formatting and spelling updates
Signed-off-by: Mike Rapoport --- Documentation/vm/numa_memory_policy.rst | 24 +--- 1 file changed, 17 insertions(+), 7 deletions(-) diff --git a/Documentation/vm/numa_memory_policy.rst b/Documentation/vm/numa_memory_policy.rst index 8cd942c..ac0b396 100644 --- a/Documentation/vm/numa_memory_policy.rst +++ b/Documentation/vm/numa_memory_policy.rst @@ -44,14 +44,20 @@ System Default Policy allocations. Task/Process Policy - this is an optional, per-task policy. When defined for a specific task, this policy controls all page allocations made by or on behalf of the task that aren't controlled by a more specific scope. If a task does not define a task policy, then all page allocations that would have been controlled by the task policy "fall back" to the System Default Policy. + this is an optional, per-task policy. When defined for a + specific task, this policy controls all page allocations made + by or on behalf of the task that aren't controlled by a more + specific scope. If a task does not define a task policy, then + all page allocations that would have been controlled by the + task policy "fall back" to the System Default Policy. The task policy applies to the entire address space of a task. Thus, it is inheritable, and indeed is inherited, across both fork() [clone() w/o the CLONE_VM flag] and exec*(). This allows a parent task to establish the task policy for a child task exec()'d from an executable image that has no awareness of memory policy. See the - MEMORY POLICY APIS section, below, for an overview of the system call + :ref:`Memory Policy APIs ` section, + below, for an overview of the system call that a task may use to set/change its task/process policy. In a multi-threaded task, task policies apply only to the thread @@ -70,12 +76,13 @@ Task/Process Policy VMA Policy A "VMA" or "Virtual Memory Area" refers to a range of a task's virtual address space. A task may define a specific policy for a range - of its virtual address space. See the MEMORY POLICIES APIS section, + of its virtual address space. See the + :ref:`Memory Policy APIs ` section, below, for an overview of the mbind() system call used to set a VMA policy. A VMA policy will govern the allocation of pages that back - this region ofthe address space. Any regions of the task's + this region of the address space. Any regions of the task's address space that don't have an explicit VMA policy will fall back to the task policy, which may itself fall back to the System Default Policy. @@ -117,7 +124,7 @@ VMA Policy Shared Policy Conceptually, shared policies apply to "memory objects" mapped shared into one or more tasks' distinct address spaces. An - application installs a shared policies the same way as VMA + application installs shared policies the same way as VMA policies--using the mbind() system call specifying a range of virtual addresses that map the shared object. However, unlike VMA policies, which can be considered to be an attribute of a @@ -135,7 +142,7 @@ Shared Policy Although hugetlbfs segments now support lazy allocation, their support for shared policy has not been completed. - As mentioned above :ref:`VMA policies `, + As mentioned above in :ref:`VMA policies ` section, allocations of page cache pages for regular files mmap()ed with MAP_SHARED ignore any VMA policy installed on the virtual address range backed by the shared file mapping. Rather, @@ -245,7 +252,7 @@ MPOL_F_STATIC_NODES the user should not be remapped if the task or VMA's set of allowed nodes changes after the memory policy has been defined. - Without this flag, anytime a mempolicy is rebound because of a + Without this flag, any time a mempolicy is rebound because of a change in the set of allowed nodes, the node (Preferred) or nodemask (Bind, Interleave) is remapped to the new set of allowed nodes. This may result in nodes being used that were @@ -389,7 +396,10 @@ follows: or by prefaulting the entire shared memory region into memory and locking it down. However, this might not be appropriate for all applications. +.. _memory_policy_apis: + Memory Policy APIs +== Linux supports 3 system calls for controlling memory policy. These APIS always affect only the calling task, the calling task's address space, or -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/3] docs/vm: move numa_memory_policy.rst to admin-guide/mm
Hi,
These patches include minor formatting and spelling updates to
Documentation/vm/numa_memory_policy.rst and move this file to
Documentation/admin-guide/mm.
Mike Rapoport (3):
docs/vm: numa_memory_policy: formatting and spelling updates
docs/vm: numa_memory_policy: s/Linux memory policy/NUMA memory policy/
docs/vm: move numa_memory_policy.rst to Documentation/admin-guide/mm
Documentation/admin-guide/mm/hugetlbpage.rst | 2 +-
Documentation/admin-guide/mm/index.rst | 1 +
.../{vm => admin-guide/mm}/numa_memory_policy.rst | 38 ++
Documentation/filesystems/proc.txt | 2 +-
Documentation/filesystems/tmpfs.txt| 5 +--
Documentation/vm/00-INDEX | 2 --
Documentation/vm/index.rst | 1 -
Documentation/vm/numa.rst | 2 +-
8 files changed, 31 insertions(+), 22 deletions(-)
rename Documentation/{vm => admin-guide/mm}/numa_memory_policy.rst (95%)
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-doc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/3] docs/vm: move numa_memory_policy.rst to Documentation/admin-guide/mm
The document describes userspace API and as such it belongs to
Documentation/admin-guide/mm
Signed-off-by: Mike Rapoport
---
Documentation/admin-guide/mm/hugetlbpage.rst| 2 +-
Documentation/admin-guide/mm/index.rst | 1 +
Documentation/{vm => admin-guide/mm}/numa_memory_policy.rst | 0
Documentation/filesystems/proc.txt | 2 +-
Documentation/filesystems/tmpfs.txt | 5 +++--
Documentation/vm/00-INDEX | 2 --
Documentation/vm/index.rst | 1 -
Documentation/vm/numa.rst | 2 +-
8 files changed, 7 insertions(+), 8 deletions(-)
rename Documentation/{vm => admin-guide/mm}/numa_memory_policy.rst (100%)
diff --git a/Documentation/admin-guide/mm/hugetlbpage.rst
b/Documentation/admin-guide/mm/hugetlbpage.rst
index a8b0806..1cc0bc7 100644
--- a/Documentation/admin-guide/mm/hugetlbpage.rst
+++ b/Documentation/admin-guide/mm/hugetlbpage.rst
@@ -220,7 +220,7 @@ memory policy mode--bind, preferred, local or
interleave--may be used. The
resulting effect on persistent huge page allocation is as follows:
#. Regardless of mempolicy mode [see
- :ref:`Documentation/vm/numa_memory_policy.rst `],
+ :ref:`Documentation/admin-guide/mm/numa_memory_policy.rst
`],
persistent huge pages will be distributed across the node or nodes
specified in the mempolicy as if "interleave" had been specified.
However, if a node in the policy does not contain sufficient contiguous
diff --git a/Documentation/admin-guide/mm/index.rst
b/Documentation/admin-guide/mm/index.rst
index ad28644..a69aa69 100644
--- a/Documentation/admin-guide/mm/index.rst
+++ b/Documentation/admin-guide/mm/index.rst
@@ -24,6 +24,7 @@ the Linux memory management.
hugetlbpage
idle_page_tracking
ksm
+ numa_memory_policy
pagemap
soft-dirty
userfaultfd
diff --git a/Documentation/vm/numa_memory_policy.rst
b/Documentation/admin-guide/mm/numa_memory_policy.rst
similarity index 100%
rename from Documentation/vm/numa_memory_policy.rst
rename to Documentation/admin-guide/mm/numa_memory_policy.rst
diff --git a/Documentation/filesystems/proc.txt
b/Documentation/filesystems/proc.txt
index ef53f80..520f6a8 100644
--- a/Documentation/filesystems/proc.txt
+++ b/Documentation/filesystems/proc.txt
@@ -566,7 +566,7 @@ address policymapping details
Where:
"address" is the starting address for the mapping;
-"policy" reports the NUMA memory policy set for the mapping (see
vm/numa_memory_policy.txt);
+"policy" reports the NUMA memory policy set for the mapping (see
Documentation/admin-guide/mm/numa_memory_policy.rst);
"mapping details" summarizes mapping data such as mapping type, page usage
counters,
node locality page counters (N0 == node0, N1 == node1, ...) and the kernel page
size, in KB, that is backing the mapping up.
diff --git a/Documentation/filesystems/tmpfs.txt
b/Documentation/filesystems/tmpfs.txt
index 627389a..d06e9a5 100644
--- a/Documentation/filesystems/tmpfs.txt
+++ b/Documentation/filesystems/tmpfs.txt
@@ -105,8 +105,9 @@ policy for the file will revert to "default" policy.
NUMA memory allocation policies have optional flags that can be used in
conjunction with their modes. These optional flags can be specified
when tmpfs is mounted by appending them to the mode before the NodeList.
-See Documentation/vm/numa_memory_policy.rst for a list of all available
-memory allocation policy mode flags and their effect on memory policy.
+See Documentation/admin-guide/mm/numa_memory_policy.rst for a list of
+all available memory allocation policy mode flags and their effect on
+memory policy.
=static is equivalent toMPOL_F_STATIC_NODES
=relative is equivalent toMPOL_F_RELATIVE_NODES
diff --git a/Documentation/vm/00-INDEX b/Documentation/vm/00-INDEX
index f8a96ca..f4a4f3e 100644
--- a/Documentation/vm/00-INDEX
+++ b/Documentation/vm/00-INDEX
@@ -22,8 +22,6 @@ mmu_notifier.rst
- a note about clearing pte/pmd and mmu notifications
numa.rst
- information about NUMA specific code in the Linux vm.
-numa_memory_policy.rst
- - documentation of concepts and APIs of the 2.6 memory policy support.
overcommit-accounting.rst
- description of the Linux kernels overcommit handling modes.
page_frags.rst
diff --git a/Documentation/vm/index.rst b/Documentation/vm/index.rst
index ed58cb9..8e1cc66 100644
--- a/Documentation/vm/index.rst
+++ b/Documentation/vm/index.rst
@@ -14,7 +14,6 @@ various features of the Linux memory management
:maxdepth: 1
ksm
- numa_memory_policy
transhuge
swap_numa
zswap
diff --git a/Documentation/vm/numa.rst b/Documentation/vm/numa.rst
index aada84b..185d8a5 100644
--- a/Documentation/vm/numa.rst
+++ b/Documentation/vm/numa.rst
@@ -110,7 +110,7 @@ to improve NUMA locality using various CPU affinity command
line interfaces
[PATCH 2/3] docs/vm: numa_memory_policy: s/Linux memory policy/NUMA memory policy/
The document describes NUMA memory policy and as it is a part of the Linux documentation it's obvious that this is Linux memory policy. Besides, "Linux memory policy" may refer to other policies, e.g. memory hotplug policy, and using term NUMA makes the documentation less ambiguous. Signed-off-by: Mike Rapoport --- Documentation/vm/numa_memory_policy.rst | 14 +++--- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/Documentation/vm/numa_memory_policy.rst b/Documentation/vm/numa_memory_policy.rst index ac0b396..d78c5b3 100644 --- a/Documentation/vm/numa_memory_policy.rst +++ b/Documentation/vm/numa_memory_policy.rst @@ -1,10 +1,10 @@ .. _numa_memory_policy: -=== -Linux Memory Policy -=== +== +NUMA Memory Policy +== -What is Linux Memory Policy? +What is NUMA Memory Policy? In the Linux kernel, "memory policy" determines from which node the kernel will @@ -162,7 +162,7 @@ Shared Policy Components of Memory Policies - -A Linux memory policy consists of a "mode", optional mode flags, and +A NUMA memory policy consists of a "mode", optional mode flags, and an optional set of nodes. The mode determines the behavior of the policy, the optional mode flags determine the behavior of the mode, and the optional set of nodes can be viewed as the arguments to the @@ -172,7 +172,7 @@ Internally, memory policies are implemented by a reference counted structure, struct mempolicy. Details of this structure will be discussed in context, below, as required to explain the behavior. -Linux memory policy supports the following 4 behavioral modes: +NUMA memory policy supports the following 4 behavioral modes: Default Mode--MPOL_DEFAULT This mode is only used in the memory policy APIs. Internally, @@ -245,7 +245,7 @@ MPOL_INTERLEAVED address range or file. During system boot up, the temporary interleaved system default policy works in this mode. -Linux memory policy supports the following optional mode flags: +NUMA memory policy supports the following optional mode flags: MPOL_F_STATIC_NODES This flag specifies that the nodemask passed by -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
