Displaying 20 results from an estimated 23 matches for "atomic_long_t".
2015 Oct 07
3
[PATCH] drm/virtio: use %llu format string form atomic64_t
...ave to wonder why atomic64_* functions do not use u64 types.
> If they're not reliant on manipulating 64-bit quantities, then what's
> the point of calling them atomic _64_.
I haven't checked all architectures, but I assume what happens is that
64-bit ones just #define atomic64_t atomic_long_t, so they don't have
to provide three sets of functions.
Arnd
2015 Oct 07
3
[PATCH] drm/virtio: use %llu format string form atomic64_t
...ave to wonder why atomic64_* functions do not use u64 types.
> If they're not reliant on manipulating 64-bit quantities, then what's
> the point of calling them atomic _64_.
I haven't checked all architectures, but I assume what happens is that
64-bit ones just #define atomic64_t atomic_long_t, so they don't have
to provide three sets of functions.
Arnd
2015 Oct 19
1
[PATCH] drm/virtio: use %llu format string form atomic64_t
On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote:
> > I haven't checked all architectures, but I assume what happens is that
> > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
> > to provide three sets of functions.
>
> scratch that, I just looked at all the architectures and found that it's
> just completely arbitrary, even within one architecture you get a mix
> of 'long' and 'long long', plus this gem from...
2015 Oct 19
1
[PATCH] drm/virtio: use %llu format string form atomic64_t
On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote:
> > I haven't checked all architectures, but I assume what happens is that
> > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
> > to provide three sets of functions.
>
> scratch that, I just looked at all the architectures and found that it's
> just completely arbitrary, even within one architecture you get a mix
> of 'long' and 'long long', plus this gem from...
2020 Nov 03
0
[patch V3 22/37] highmem: High implementation details and document API
...pfn(unsigned long pfn)
+{
+ preempt_disable();
+ pagefault_disable();
+ return __kmap_local_pfn_prot(pfn, kmap_prot);
+}
+
+static inline void __kunmap_atomic(void *addr)
+{
+ kunmap_local_indexed(addr);
+ pagefault_enable();
+ preempt_enable();
+}
+
+unsigned int __nr_free_highpages(void);
+extern atomic_long_t _totalhigh_pages;
+
+static inline unsigned int nr_free_highpages(void)
+{
+ return __nr_free_highpages();
+}
+
+static inline unsigned long totalhigh_pages(void)
+{
+ return (unsigned long)atomic_long_read(&_totalhigh_pages);
+}
+
+static inline void totalhigh_pages_inc(void)
+{
+ atomic_long_...
2020 Nov 03
0
[patch V3 19/37] mm/highmem: Remove the old kmap_atomic cruft
...tic inline void __kunmap_atomic(void
kunmap_local_indexed(addr);
}
-#endif /* CONFIG_KMAP_LOCAL */
-
-static inline void *kmap_atomic(struct page *page)
-{
- return kmap_atomic_prot(page, kmap_prot);
-}
-
/* declarations for linux/mm/highmem.c */
unsigned int nr_free_highpages(void);
extern atomic_long_t _totalhigh_pages;
@@ -212,41 +190,8 @@ static inline void __kunmap_atomic(void
#define kmap_flush_unused() do {} while(0)
-#endif /* CONFIG_HIGHMEM */
-
-#if !defined(CONFIG_KMAP_LOCAL)
-#if defined(CONFIG_HIGHMEM)
-
-DECLARE_PER_CPU(int, __kmap_atomic_idx);
-
-static inline int kmap_atomic_id...
2020 Nov 03
0
[patch V3 01/37] mm/highmem: Un-EXPORT __kmap_atomic_idx()
...>
Reviewed-by: Christoph Hellwig <hch at lst.de>
Cc: Andrew Morton <akpm at linux-foundation.org>
Cc: linux-mm at kvack.org
---
mm/highmem.c | 2 --
1 file changed, 2 deletions(-)
--- a/mm/highmem.c
+++ b/mm/highmem.c
@@ -108,8 +108,6 @@ static inline wait_queue_head_t *get_pkm
atomic_long_t _totalhigh_pages __read_mostly;
EXPORT_SYMBOL(_totalhigh_pages);
-EXPORT_PER_CPU_SYMBOL(__kmap_atomic_idx);
-
unsigned int nr_free_highpages (void)
{
struct zone *zone;
2015 Oct 07
0
[PATCH] drm/virtio: use %llu format string form atomic64_t
...4_* functions do not use u64 types.
> > If they're not reliant on manipulating 64-bit quantities, then what's
> > the point of calling them atomic _64_.
>
> I haven't checked all architectures, but I assume what happens is that
> 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
> to provide three sets of functions.
scratch that, I just looked at all the architectures and found that it's
just completely arbitrary, even within one architecture you get a mix
of 'long' and 'long long', plus this gem from MIPS:
static __inline__...
2015 Oct 19
0
[PATCH] drm/virtio: use %llu format string form atomic64_t
On Monday 19 October 2015 11:37:00 Ralf Baechle wrote:
> On Wed, Oct 07, 2015 at 01:23:07PM +0200, Arnd Bergmann wrote:
>
> > > I haven't checked all architectures, but I assume what happens is that
> > > 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
> > > to provide three sets of functions.
> >
> > scratch that, I just looked at all the architectures and found that it's
> > just completely arbitrary, even within one architecture you get a mix
> > of 'long' and 'long long...
2015 Oct 07
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
The virtgpu driver prints the last_seq variable using the %ld or
%lu format string, which does not work correctly on all architectures
and causes this compiler warning on ARM:
drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str':
drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but
2015 Oct 07
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
The virtgpu driver prints the last_seq variable using the %ld or
%lu format string, which does not work correctly on all architectures
and causes this compiler warning on ARM:
drivers/gpu/drm/virtio/virtgpu_fence.c: In function 'virtio_timeline_value_str':
drivers/gpu/drm/virtio/virtgpu_fence.c:64:22: warning: format '%lu' expects argument of type 'long unsigned int', but
2015 Oct 19
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
...t use u64 types.
>> > If they're not reliant on manipulating 64-bit quantities, then what's
>> > the point of calling them atomic _64_.
>>
>> I haven't checked all architectures, but I assume what happens is that
>> 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
>> to provide three sets of functions.
>
> scratch that, I just looked at all the architectures and found that it's
> just completely arbitrary, even within one architecture you get a mix
> of 'long' and 'long long', plus this gem from M...
2015 Oct 19
2
[PATCH] drm/virtio: use %llu format string form atomic64_t
...t use u64 types.
>> > If they're not reliant on manipulating 64-bit quantities, then what's
>> > the point of calling them atomic _64_.
>>
>> I haven't checked all architectures, but I assume what happens is that
>> 64-bit ones just #define atomic64_t atomic_long_t, so they don't have
>> to provide three sets of functions.
>
> scratch that, I just looked at all the architectures and found that it's
> just completely arbitrary, even within one architecture you get a mix
> of 'long' and 'long long', plus this gem from M...
2009 Aug 24
1
[PATCH 1/8] blkio-cgroup-v11: Introduction
...kio-cgroup v11.
Changes:
- The function cgroup_get_from_page() is added which determines to
which cgroup a given page belongs. This function is introduced from
Vivek's io-controller patch. Thanks Vivek.
- Fix a type mismatch of the refcount of io_context. The refcount has
been changed to atomic_long_t.
This patch can be applied to 2.6.31-rc7.
The list of the patches:
[PATCH 1/8] blkio-cgroup-v11: Introduction
[PATCH 2/8] blkio-cgroup-v11: The new page_cgroup framework
[PATCH 3/8] blkio-cgroup-v11: Refactoring io-context initialization
[PATCH 4/8] blkio-cgroup-v11: The body of blkio-cgr...
2009 Aug 24
1
[PATCH 1/8] blkio-cgroup-v11: Introduction
...kio-cgroup v11.
Changes:
- The function cgroup_get_from_page() is added which determines to
which cgroup a given page belongs. This function is introduced from
Vivek's io-controller patch. Thanks Vivek.
- Fix a type mismatch of the refcount of io_context. The refcount has
been changed to atomic_long_t.
This patch can be applied to 2.6.31-rc7.
The list of the patches:
[PATCH 1/8] blkio-cgroup-v11: Introduction
[PATCH 2/8] blkio-cgroup-v11: The new page_cgroup framework
[PATCH 3/8] blkio-cgroup-v11: Refactoring io-context initialization
[PATCH 4/8] blkio-cgroup-v11: The body of blkio-cgr...
2009 Aug 24
1
[PATCH 1/8] blkio-cgroup-v11: Introduction
...kio-cgroup v11.
Changes:
- The function cgroup_get_from_page() is added which determines to
which cgroup a given page belongs. This function is introduced from
Vivek's io-controller patch. Thanks Vivek.
- Fix a type mismatch of the refcount of io_context. The refcount has
been changed to atomic_long_t.
This patch can be applied to 2.6.31-rc7.
The list of the patches:
[PATCH 1/8] blkio-cgroup-v11: Introduction
[PATCH 2/8] blkio-cgroup-v11: The new page_cgroup framework
[PATCH 3/8] blkio-cgroup-v11: Refactoring io-context initialization
[PATCH 4/8] blkio-cgroup-v11: The body of blkio-cgr...
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all
2020 Nov 03
45
[patch V3 00/37] mm/highmem: Preemptible variant of kmap_atomic & friends
Following up to the discussion in:
https://lore.kernel.org/r/20200914204209.256266093 at linutronix.de
and the second version of this:
https://lore.kernel.org/r/20201029221806.189523375 at linutronix.de
this series provides a preemptible variant of kmap_atomic & related
interfaces.
This is achieved by:
- Removing the RT dependency from migrate_disable/enable()
- Consolidating all
2016 Oct 24
0
[PATCH v3 34/37] docs: fix locations of several documents that got moved
...e type
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index c9d1cacb4395..7281bf939779 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -16,7 +16,7 @@ will fail. Something like the following should suffice:
typedef struct { long counter; } atomic_long_t;
Historically, counter has been declared volatile. This is now discouraged.
-See Documentation/volatile-considered-harmful.txt for the complete rationale.
+See Documentation/process/volatile-considered-harmful.rst for the complete rationale.
local_t is very similar to atomic_t. If the counte...