GFP flags and the end of __GFP

By Jonathan Corbet
January 27, 2023

Memory allocation within the kernel is a complex business. The amount of physical memory available on any given system will be strictly limited, meaning that an allocation request can often only be satisfied by taking memory from somebody else, but some of the options for reclaiming memory may not be available when a request is made. Additionally, some allocation requests have requirements dictating where that memory can be placed or how quickly the allocation must be made. The kernel's memory-allocation functions have long supported a set of "GFP flags" used to describe the requirements of each specific request. Those flags will probably undergo some changes soon as the result of this patch set posted by Mel Gorman; that provides an opportunity to look at those flags in some detail.

The "GFP" in GFP flags initially stood for "get free page", referring to __get_free_pages(), a longstanding, low-level allocation function in the kernel. GFP flags are used far beyond that function, but it's worth remembering that they are relevant to full-page allocations. Functions (like kmalloc()) that allocate smaller chunks of memory may take GFP flags, but they are only used when those functions must get full pages from the memory-management subsystem.

Most developers see GFP flags in the form of macros like GFP_ATOMIC or GFP_KERNEL, but those macros are actually constructs made up of lower-level flags. Thus, for example, in the 6.2-rc kernels, GFP_ATOMIC is defined as:

    #define GFP_ATOMIC	(__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM)

Each of the component flags modifies the request in some way; __GFP_HIGH marks it as a "high priority" request, for example, with implications that will be described below. Back in 2021, though, Neil Brown observed that "__GFP_ATOMIC serves little purpose" and posted a patch to remove it. That patch languished for over a year, though it did inspire a slow-moving conversation on the meaning of certain GFP flags. In October, Andrew Morton threatened to drop it. That inspired Gorman to pick it up and fold it into the current series, which makes a number of changes to how the low-level GFP flags work.

Low-level GFP flags

These flags are defined in include/linux/gfp_types.h. There are multiple variants of each flag. Thus, for example, __GFP_ATOMIC is defined as:

    #define __GFP_ATOMIC	((__force gfp_t)___GFP_ATOMIC)

While the three-underscore ___GFP_ATOMIC is simply defined as:

    #define ___GFP_ATOMIC		0x200u

The intermediate (two-underscore) level of flags is there to enable type checking for the GFP-flags argument to a number of functions, while the three-underscore level allows easy manipulation within the memory-management subsystem. Developers outside of that subsystem should not use the three-underscore versions, but they are the ones that, in the end, define the options that are available with memory-allocation requests.

So, for the curious, here is the set of low-level GFP flags and their effect on allocation requests after the application of Gorman's patch set, grouped into a few broad categories.

Placement options

A number of GFP flags affect where an allocation is located in physical memory:

___GFP_DMA: This is an ancient flag reflecting the limitations of early x86 systems, which could only support 24-bit DMA addresses on the ISA bus; it caused the allocation to be placed in the lowest 16MB of physical memory. Even the worst hardware supported on current systems should not suffer from this limitation but, as gfp_types.h notes, it cannot be easily removed: "careful auditing" would be required.
___GFP_DMA32: Like ___GFP_DMA, this flag is for devices with a limited DMA range; this one restricts the allocation to physical memory that is addressable with 32 bits. This flag, hopefully, is only needed with older hardware that had a hard time making the 64-bit transition.
___GFP_HIGHMEM: This flag indicates that "high memory" can be used to satisfy the allocation request. High memory is described in this article; it only exists on 32-bit systems where it is not possible to map all of physical memory into the kernel's address space. There is no high memory on 64-bit systems, so this flag has no effect there.
___GFP_MOVABLE: Indicates memory that can be moved by the memory-management subsystem if needed to help the reclaim process. User-space pages, for example, are movable since they are accessed via page tables that can be updated to a new location without the owning process noticing.
___GFP_RECLAIMABLE: This flag indicates slab memory that can be reclaimed via shrinkers when resources get tight. The memory-management subsystem tries to keep both movable and reclaimable allocations together in the same memory zones to facilitate the freeing of larger ranges of memory when needed.
___GFP_HARDWALL: This flag disallows the allocation of memory outside of the memory nodes in the calling process's cpuset.
___GFP_THISNODE: Allocations with this flag can only be satisfied by memory that is on the current NUMA node.

Access to reserves

The memory-management subsystem works hard to keep a reserve of free memory at all times. Freeing memory can often require allocating memory first — to set up an I/O transfer to write the contents of dirty pages to persistent storage, for example — and things go badly indeed if that allocation fails. There are a few options describing whether an allocation can eat into the reserves, and by how much.

___GFP_HIGH: "High-priority" allocations are marked with this flag. What this means in practice, as stabilized by Gorman's patch set, is that the allocation is allowed to dip into the memory reserves that the kernel keeps for important allocations. With this flag, a request is allowed to deplete the reserves down to 50% of their normal size.
___GFP_MEMALLOC: An allocation with this flag will bypass all limits on use of reserves, grabbing any chunk of memory that is available. It is only intended to be used in cases where the allocation is done with the purpose of making more memory available in the near future.
___GFP_NOMEMALLOC: Explicitly disables any access to memory reserves. This flag was initially introduced to prevent memory pools from running down the kernel's reserves.

Note that ___GFP_KSWAPD_RECLAIM, described below, also has an effect on the use of reserves.

Side effects

An allocation request made from atomic context cannot be allowed to block, and requests made from a filesystem should not cause a recursive call back into that filesystem. A few of the defined GFP flags reflect these constraints, describing what the memory-management subsystem is allowed to do to satisfy a request:

___GFP_IO: Requests with this flag are allowed to start I/O if needed to reclaim memory. It will be present for "normal" requests, but missing for requests made from within the storage layer, for example, where recursive I/O operations should be avoided.
___GFP_FS: This flag allows the request to call into the filesystem layer if needed to reclaim memory; like ___GFP_IO, it is used (by its absence) to avoid recursive calls when the filesystem itself is allocating memory.
___GFP_DIRECT_RECLAIM: Allows the allocation call to enter direct reclaim, meaning that the calling thread can, itself, be put to work freeing memory to satisfy the allocation. Direct reclaim increases the chances of the allocation succeeding, but can also increase the latency of the request and may cause the calling thread to block.
___GFP_KSWAPD_RECLAIM: This flag allows the kswapd process to be invoked to perform reclaim. That is normally desired, but there are cases where having kswapd running could interfere with other memory-management operations. Less obviously (but perhaps more importantly), this flag also indicates that the allocation request should not block for any reason; indeed, GFP_NOWAIT is a synonym for this flag. If ___GFP_HIGH is also set, this flag will allow access to 62.5% of the memory reserves.

Warnings and retries

Yet another set of options describes what should be done if an initial attempt to fulfill an allocation request fails:

___GFP_NOWARN: Prevents the printing of warnings in the system log should the request fail. This flag is used in cases where failures may be expected and there is a readily available workaround available; an example would be an attempt to allocate a large, contiguous area where it is possible to get by with a lot of smaller allocations if need be.
___GFP_RETRY_MAYFAIL: Indicates a request that is important and which can wait for additional retries if the first attempt at allocation fails.
___GFP_NOFAIL: Marks a request that cannot be allowed to fail; the memory-management subsystem will retry indefinitely in this case. There have been occasional attempts to remove this flag on the theory that all kernel code should be able to handle allocation failures, but there are still quite a few uses of it.
___GFP_NORETRY: This flag will cause an allocation request to fail quickly if memory is not readily available. It is useful in places where allocation failures can be handled relatively easily and it is better to not stress the system by trying harder to reclaim memory.

Miscellaneous flags

Finally, there is the inevitable set of flags that don't fit into any other category:

___GFP_ZERO: This flag requests that the requested page(s) be zeroed before being returned.
___GFP_WRITE: Indicates that the page will be written to soon. This flag is only observed in a couple of spots. One is to try to spread to-be-written pages across memory zones. The other is a tweak to the "refault" code that handles a process's working set; if a previously reclaimed file page is brought back in to be rewritten, it is not treated as part of the working set.
___GFP_COMP: A multi-page allocation should return a compound page.
___GFP_ACCOUNT: This flag causes the allocation to be charged to the current process's control group. It is only used for allocations to be used within the kernel; user-space pages are already accounted in this way.
___GFP_ZEROTAGS: Causes the internal "tags" metadata associated with the page to be cleared if the page itself is being zeroed on allocation. This is a minor optimization that is used in exactly one place in the arm64 page-fault-handling code.
___GFP_SKIP_ZERO
___GFP_SKIP_KASAN_UNPOISON
___GFP_SKIP_KASAN_POISON: These three flags are used to tweak the checking by the KASAN sanitizer.
___GFP_NOLOCKDEP: Disables checking of the allocation context done by the lockdep locking checker. This flag is only used within the memory-management subsystem and XFS filesystem.

In conclusion

As can be seen, there are a lot of ways to modify how memory allocation is done in the kernel. After Gorman's patch series, GFP_ATOMIC still exists (there are over 5,000 call sites in the kernel, after all), but it is defined as:

    #define GFP_ATOMIC	(__GFP_HIGH|__GFP_KSWAPD_RECLAIM)

So, from the list above, we see that a GFP_ATOMIC allocation request will never block, and it has deep access to the kernel's memory reserves. That is why use of GFP_ATOMIC is discouraged in any situation where it is not truly necessary.

One other change made in this patch set is to treat allocations made by realtime tasks as being implicitly marked as ___GFP_HIGH, since dipping into the reserves is seen as better than delaying the task and causing it to miss a deadline. But, as Gorman pointed out, if access to reserves is needed, the system is under memory pressure and chances are good that the deadlines aren't going to work out anyway. The patch warns that the special-case for realtime tasks will be removed at some point in the future.

This patch series is in its third iteration, not counting Brown's initial posting. The discussion seems to have slowed down, so it is looking like it is close to ready to head into the mainline. Then ___GFP_ATOMIC will be no more, some of the other flags will be a bit better defined — and most developers presumably will not even notice.

Index entries for this article
Kernel	Memory management/GFP flags
Kernel	Releases/6.3

GFP flags and the end of GFP_ATOMIC

Posted Jan 29, 2023 22:35 UTC (Sun) by gb (subscriber, #58328) [Link] (2 responses)

I read article twice (with interest), but it seems that there is nothing about what is so bad about _*GFP_ATOMIC?
Does it spins? Is it really mean atomic (only one allocation could happen in parallel)?
What is problem being solved?

GFP flags and the end of GFP_ATOMIC

Posted Jan 31, 2023 6:52 UTC (Tue) by neilbrown (subscriber, #359) [Link] (1 responses)

> What is problem being solved?

Problem was that this maze of twisty __GFP_* flags was confusing my poor brain.

__GFP_ATOMIC doesn't mean any one thing. If you follow the link to my original email (which I had to do to refresh my memory) you will see that __GFP_ATOMIC has a motley assortment of tasks that don't really fit any pattern.

__GFP_ATOMIC is *always* paired with __GFP_HIGH, and much of the __GFP_ATOMIC functionally is really increasing the priority of the allocation in some way. So maybe __GFP_HIGH should be used. Or maybe __GFP_ATOMIC should be renamed __GFP_HIGHER. Or something.

After some deeper analysis, it seemed that there was no convincing need for multiple levels of HIGHness, so we agreed to let it disappear.

Mel then did some more revising and refining so that some of the remaining flags have clearer and better documented meanings.

Net result: the next time I have to dive into this code, I can expect less confusion (or at least - different confusion).

Problem solved!

GFP flags and the end of GFP_ATOMIC

Posted Jan 31, 2023 19:19 UTC (Tue) by gb (subscriber, #58328) [Link]

Thanks, article makes sense now.

GFP flags and the end of GFP_ATOMIC

Posted Jan 30, 2023 1:42 UTC (Mon) by intelfx (subscriber, #130118) [Link] (1 responses)

Wait. Is it GFP_ATOMIC going away? My impression from reading the patch set that it was __GFP_ATOMIC, not the actual kernel-code-facing GFP_ATOMIC.

With the patch applied, the actual GFP_ATOMIC will simply mean (__GFP_HIGH|__GFP_KSWAPD_RECLAIM) instead of (__GFP_HIGH|__GFP_ATOMIC|__GFP_KSWAPD_RECLAIM).

GFP flags and the end of GFP_ATOMIC

Posted Jan 30, 2023 14:33 UTC (Mon) by corbet (editor, #1) [Link]

No, GFP_ATOMIC isn't going away, as the article says. The headline really needed the two-underscore __GFP_ATOMIC, which is probably going away. I'll go fix that now, sorry for the confusion.

GFP flags and the end of __GFP_ATOMIC

Posted Jan 30, 2023 15:07 UTC (Mon) by ianmcc (guest, #88379) [Link] (32 responses)

How does ___GFP_KSWAPD_RECLAIM invoke kswapd without blocking? I asked ChatGPT, and it claims that it will fail with an error while kswapd reclaims memory in the background, which seems strange. I would have thought (coming at this from a non-kernel developer) that the more common operation would be to block until memory is actually available.

Invoking kswapd

Posted Jan 30, 2023 15:44 UTC (Mon) by corbet (editor, #1) [Link] (7 responses)

The whole point of __GFP_KSWAPD_RECLAIM is to not block - that's why GFP_NOWAIT appears as a synonym. It's used in situations where blocking is simply not an option.

Invoking kswapd

Posted Jan 30, 2023 19:13 UTC (Mon) by geert (subscriber, #98403) [Link] (3 responses)

| This flag allows the kswapd process to be invoked to perform reclaim.

How do you invoke another process without blocking?

Invoking kswapd

Posted Jan 30, 2023 19:20 UTC (Mon) by corbet (editor, #1) [Link] (2 responses)

Wake it up and let it be scheduled as usual?

The point that didn't come through, perhaps, is that invoking the process is not the same as waiting for it to get anything done.

Invoking kswapd

Posted Jan 31, 2023 9:16 UTC (Tue) by geert (subscriber, #98403) [Link] (1 responses)

OK, so this kicks kswapd, but doesn't have any immediate gain for the memory allocation request that triggers it, as it cannot wait for any action performed by kswapd?

Invoking kswapd

Posted Feb 20, 2023 11:22 UTC (Mon) by karim96 (subscriber, #153187) [Link]

The kernel wakes up kswapd as soon as the fast allocation path fails.
Then it enters the slow path and tries to concurrently allocate memory while
kswapd is running (in the hope that kswapd frees something meanwhile).
The slow path is a huge loop that tries the allocation several times with different policies
(e.g. ALLOC_HARDER, ALLOC_NO_WATERMARKS, etc), gradually increasing the pressure,
all while kswapd is also trying to free something.

Invoking kswapd

Posted Jan 31, 2023 7:08 UTC (Tue) by neilbrown (subscriber, #359) [Link] (2 responses)

> The whole point of __GFP_KSWAPD_RECLAIM is to not block - that's why GFP_NOWAIT appears as a synonym. It's used in situations where blocking is simply not an option.

That isn't quite how I understand it.

The whole point of __GFP_KSWAPD_RECLAIM is to wake up kswapd if reclaim is needed. No more, no less.

According to https://lore.kernel.org/all/YZz6QWlk%2FZMzC4DG@dhcp22.sus... that flag dates back to https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/... (which does something about allocating transparent-huge-pages).

The implication seems to be that most callers will want kswapd to start, but there are a few special cases that don't. It is generally thought best that __GFP_FOO flags should trigger an action rather than suppress an action, so we have the KSWAP_RECLAIM which is almost always used.

GFP_NOWAIT doesn't want to trigger anything - certainly no IO or direct reclaim or retry or .... So "0" would be a pretty good value. But __GFP_KSWAPD_RECLAIM is almost free, so it includes that flag.

I think the only place that DOESN'T want the KSWAP_RECLAIM flag is internal to mm/ so it could probably use an internal interface which takes ALLOC_FOO flags. So maybe we could discard KSWAP_RECLAIM as well, *always* wake kswapd when reclaim is needed by external callers, and provide a way for internal-to-mm code to bypass that wake-up.

Invoking kswapd

Posted Jan 31, 2023 15:12 UTC (Tue) by corbet (editor, #1) [Link] (1 responses)

So it looks like I got a little confused, not helped by this definition in gfp_types.h:

    #define GFP_NOWAIT	(__GFP_KSWAPD_RECLAIM)

That seems actively wrong — somebody might set GFP_NOWAIT with the idea that it will prevent blocking...but it doesn't do that. __GFP_DIRECT_RECLAIM seems to be the actual flag the controls blocking.

Invoking kswapd

Posted Jan 31, 2023 21:17 UTC (Tue) by neilbrown (subscriber, #359) [Link]

> somebody might set GFP_NOWAIT with the idea that it will prevent blocking

They might, but that would be confused (but then these flags are often confusing).

GFP_NOWAIT isn't something that you "set". It is not one of several flags that can be added together.

Rather it is something you choose - something you start with.

You could equally say that GFP_NOIO prevents starting IO, but it doesn't. It is a base request that doesn't include any permission to perform IO.

A gfp arg to a function should take the form of a single GFP_FOO value, possibly or'ed with some __GFP_FOO flags.
GFP_FOO is like a position, and __GFP_FOO is like a displacement. You can add a displacement to a position and get a new position. You can add a displacement to a displacement and get a new displacement. But you cannot add a position to a position, it makes no sense.

So "GFP_NOIO | __GFP_IO" would be perfectly legal and would allow IO (it is equivalent to to GFP_NOFS).

However "GFP_KERNEL | GFP_NOWAIT" does not make sense - it is the sum of two positions.

You could argue that using "NO" if the GFP_ positions is a poor choice, and it would be hard to disagree. Finding a better name would be a challenge.

The better direction (in which steps have been taken) is to deprecate the GFP_NO* flags. Rather than GFP_NOFS we are encouraged to use memalloc_nofs_save/memalloc_nofs_restore to mark code regions where it is not safe to recursively call into filesystems. Similarly memalloc_noio_save and memalloc_noreclaim_save prevent any IO requests for memory reclaim. Whether something similar could work to make GFP_NOWAIT unnecessary, I cannot say for sure.

You typically want NOWAIT when preemption is disabled (inside spinlocks and interrupts for example) and that is easily detected. There are other times - maybe they would be happy with a name like "GFP_OPPORTUNISTIC" meaning that failure is perfectly acceptable.

I would be happy if all the "Side effects" flags (as listed in the excellent article) were deprecated and discarded, being replaced by information from the process context.

I would also be happy if the "Access to reserves" and "warns and retries" flags were combined into something more orthogonal. These flags are all about the cost of failure. Failure can be avoided either by accessing reserves, or by doing more reclaim work - using up either space or time. If the request is urgent, we use space. If the request is important, we use time. Each of these seem to have 3 levels. Using the numbers 1, 2, 3 in the levels rather than current names might make sense, though it would be even better to find a name that was meaningful to the caller (the current names are most meaningful to the implementation).

Removing __GFP_ATOMIC is really just one small step on a long road.

GFP flags and the end of __GFP_ATOMIC

Posted Feb 4, 2023 2:25 UTC (Sat) by immibis (subscriber, #105511) [Link] (23 responses)

ChatGPT is a bullshit-generator-as-a-service. You really shouldn't be asking it specific technical questions and expecting correct answers.

GFP flags and the end of __GFP_ATOMIC

Posted Feb 5, 2023 22:20 UTC (Sun) by kleptog (subscriber, #1183) [Link] (1 responses)

It doesn't really matter if ChatGPT produces produces wrong answers sometimes. The test is if it produces better answers than a google search and/or asking your colleagues. That's a *much* lower bar to hurdle.

ChatGPT

Posted Feb 6, 2023 12:23 UTC (Mon) by Jandar (subscriber, #85683) [Link]

Google produces links. The source pointed to by these links can be evaluated and judged. ChatGPT offers nothing to estimate the value of the answer.

GFP flags and the end of __GFP_ATOMIC

Posted Feb 8, 2023 11:43 UTC (Wed) by jezuch (subscriber, #52988) [Link] (20 responses)

https://www.danmcquillan.org/chatgpt.html (via jwz)

GFP flags and the end of __GFP_ATOMIC

Posted Feb 10, 2023 6:42 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (19 responses)

> Of course, the elites don't apply that to themselves, just to the rest of us. The structural injustices and supremacist perspectives layered into AI put it firmly on the path of eugenicist solutions to social problems.

Are we sure this was not written by ChatGPT with the prompt: "Write a rebuttal about AI using as many BS-words as possible"?

GFP flags and the end of __GFP_ATOMIC

Posted Feb 11, 2023 15:07 UTC (Sat) by immibis (subscriber, #105511) [Link] (18 responses)

Why do you think they are bullshit words?

GFP flags and the end of __GFP_ATOMIC

Posted Feb 11, 2023 20:55 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (17 responses)

Usually, once somebody writes "supremacist" in a non-joke context, whatever they say can be dismissed. Here it also has: "elites", "structural" and other nonsense.

GFP flags and the end of __GFP_ATOMIC

Posted Feb 27, 2023 0:37 UTC (Mon) by nix (subscriber, #2304) [Link] (14 responses)

He literally had a literal link a few paras earlier showing how easy it is to get ChatGPT to assign dollar values to human lives based on the colour of their skin (and to assign intelligence levels and torture recommendations based on the same thing). All you have to do is ask it.

Honestly his usage seems downright *moderate* to me.

GFP flags and the end of __GFP_ATOMIC

Posted Feb 27, 2023 1:45 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (13 responses)

ChatGPT is a text generator. You can ask it to explain how automatic text generators have no morals and can be used for any purpose.

The author above implies that the "elites" will use ChatGPT's recommendation for "eugenicist solutions to social problems", because "we are all 'stochastic parrots'".

Honestly, this whole diatribe is deep in the tinfoil-hat category. Heck, it's probably in the lead pants category.

GFP flags and the end of __GFP_ATOMIC

Posted Feb 27, 2023 12:56 UTC (Mon) by excors (subscriber, #95769) [Link] (12 responses)

I don't think that's what the article is about - it's not saying the "elites" will simply follow ChatGPT's bad recommendations. The quote posted earlier is not really about ChatGPT at all; it's about "AI" more generally, and why businesses and governments are investing so much in it. ChatGPT is just the most prominent step in that decades-long project, so it's the hook to get people interested in the wider topic.

In this context, I think "AI" means 'any decision-making algorithm where we don't really understand how it's making decisions but we trust its decisions anyway'. It's opaque and unaccountable, which is great when you're a businessperson or politician trying to quietly implement an unpopular policy. Or maybe you're not even trying to implement that policy, it just happens by accident. Either way it's cheaper than employing humans, so you can take your share of the company's increased profits, or you can campaign on the 'efficiency savings' that will fund your popular tax cuts without cutting popular public services, and any news reports of bad outcomes can be dismissed as rare technical glitches and not your fault.

But it's very bad if you're one of the people suffering under the algorithm's wrong decisions - and that's more likely if you're a statistical outlier, on the fringes of the algorithm's training set, so this disproportionately harms already-vulnerable minorities. Plus these technologies are being deployed to address topics like welfare, crime, health, etc, which already have a (frequently problematic) dependency on race, poverty, disability, etc, so those groups will feel the greatest impact. (I think that's part of the "structural injustice", i.e. a persistent unfairness towards members of particular social groups.)

The author has a longer article at https://logicmag.io/home/deep-learning-and-human-disposab... with more concrete examples, e.g.:

> NarxCare is an analytics platform for doctors and pharmacies in the US to “instantly and automatically identify a patient’s risk of misusing opioids.” It’s an opaque and unaccountable machine learning system that trawls medical and other records to assign patients an Overdose Risk Score. One classic failing of the system has been misinterpreting medication that people had obtained for sick pets; dogs with medical problems are often prescribed opioids and benzodiazepines, and these veterinary prescriptions are made out in the owner’s name. As a result, people with a well-founded need for opioid painkillers for serious conditions like endometriosis have been denied medication by hospitals and by their own doctors.
>
> The problems with these systems go even deeper; past experience of sexual abuse has been used as a predictor of likelihood to become addicted to medication, meaning that subsequent denial of medicines becomes a kind of victim blaming. As with so much of socially applied machine learning, the algorithms simply end up identifying people with complex needs, but in a way that amplifies their abandonment.

The use of AI is still fairly limited, so much of the article is about problems in today's society where AI is not really involved - e.g. the "soft eugenic practices" of GPs giving "blanket do-not-resuscitate notices to disabled people" during Covid-19 in the UK - but (it argues) AI is being introduced to society in a way that will exacerbate these problems. Allocating scarce healthcare resources is a very emotive issue with no good solution, so it's tempting to come up with a metric that's superficially appealing (e.g. "maximise quality-adjusted life years") and then delegate the hard decisions to an algorithm that will optimise that metric with no regard for the complexities of the people it's condemning. It will also have no regard for the political context that led to the avoidable scarcity of resources, and no agency to address the root causes. And similar for many other social problems.

I think the author doesn't think that's a good direction for society to be going in, so it's important to recognise the trend and resist it.

GFP flags and the end of __GFP_ATOMIC

Posted Feb 28, 2023 22:07 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link] (11 responses)

> "elites" will simply follow ChatGPT's bad recommendations

Pretty much, yes, it does. It takes some off-the-cuff remarks and builds up a conspiracy theory around them.

There are no "elites" with any kind of a plan (heck, I wish the "Committee of 300" from the Illuminati conspiracy existed). Corporations just do what they can to maximize their profit, within the legally allowed limits. And governments are just formed of people who want to get/preserve their power.

And you can blame corporations for many things, but planning for many generations ahead is most definitely not one of them, and that's what you need if you're promoting a "eugenics agenda" or something.

ChatGPT is simply another example of automation that will result in a displacement of workers in creative areas, just as it happened with countless other professions before. Nothing more, nothing less.

GFP flags and the end of __GFP_ATOMIC

Posted Mar 1, 2023 16:47 UTC (Wed) by Wol (subscriber, #4433) [Link] (10 responses)

> Corporations just do what they can to maximize their profit, within the legally allowed limits.

Actually, in many (most) jurisdictions, corporations are LEGALLY OBLIGED to maximise their profits as much as possible. And failure to do so can be terminal as in the Vulture Capitalists will tear you apart.

Some corporations are protected by their Articles of Association, but even then ...

And over here, even Charities are affected by this. They can be forced to act to the detriment of those people they are supposed to help, in the name of maximising revenue.

Cheers,
Wol

GFP flags and the end of __GFP_ATOMIC

Posted Mar 1, 2023 17:58 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (7 responses)

I thought this came from Milton Freeman's viewpoint, not legal force. In the US (and I may very well be wrong/misinformed here), but don't the S1 and other SEC filings help to scope what the company is willing to do? Because if one is "legally obligated" to maximize profits, wouldn't every company tend towards HFT or other local maxima? Can one bring a suit against a company for not being as profitable as Apple? After all, they make more and do so (presumably) legally (nevermind the ethics of their strategies), so why not copy them and make more than you are now?

GFP flags and the end of __GFP_ATOMIC

Posted Mar 1, 2023 18:43 UTC (Wed) by Wol (subscriber, #4433) [Link] (6 responses)

> Because if one is "legally obligated" to maximize profits, wouldn't every company tend towards HFT or other local maxima?

Isn't that what happens? Yes, there are restrictions on what a company is allowed to do, hence my comment about Articles of Association, but to take a look at charities for example, assets typically MUST be sold to the highest bidder. Look at the amount of Church property that ends up in "unsuitable" hands because the charity has no say in who the purchaser is.

We've fallen foul of that - we had a Motability car, and the Government changed the rules so we no longer qualified. So the charity HAD to take the car off us. We were lucky, because so many people got caught up in this, and we were one of the last, they'd got their act together and were selling cars at book price, giving victims financial help, etc etc. But so many disabled people just got told "hand your keys back, goodbye", not because the charity wanted to, but because it had no choice.

In the normal course of events, when a lease expires, the charity takes the car back, and sells it at auction for the best price possible. It has no choice. It CAN'T sell the car at book to the disabled person, which is a damn good deal. And once a disabled person needs an adapted car, they are on a financial treadmill, where it costs a bomb to stay on the treadmill, but if they fall off they are left without transport! (That's why, when the rules changed, so many disabled people got a kick in the teeth. Standard government practice - every change in government policy for the poor and disabled comes with a heavy cost to be paid by said poor and disabled :-(

Seeing as we're no longer in that position, I don't know what's happening now, but I suspect many disabled people are stuck in the position where they are supposed to hand their cars back, but there are no (suitable) replacement cars to be had? What to do? Fortunately it's not our problem ...

You may be right, it may be Freeman not governments. But much of Freeman's attitude permeates legislation and makes it pretty much impossible for companies (and charities) to avoid Freemanomics.

Cheers,
Wol

GFP flags and the end of __GFP_ATOMIC

Posted Mar 1, 2023 21:51 UTC (Wed) by nix (subscriber, #2304) [Link] (1 responses)

(aside: the man's name is Friedman, not Freeman.)

GFP flags and the end of __GFP_ATOMIC

Posted Mar 1, 2023 22:23 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

Bah. I thought that at first but thought I was mixing it up with Sam Bankman-Fried :/ .

GFP flags and the end of __GFP_ATOMIC

Posted Mar 1, 2023 22:28 UTC (Wed) by mathstuf (subscriber, #69389) [Link] (1 responses)

That's sad. I can see *some* justification in trying to prevent fraud or money laundering via charities but it sounds to me like that is better done by enforcing existing laws to that effect rather than mandating specific behaviors.

GFP flags and the end of __GFP_ATOMIC

Posted Mar 2, 2023 5:52 UTC (Thu) by Wol (subscriber, #4433) [Link]

Well, I think a lot of the problem is "responsible steward" legislation, and risk-averse boards of trustees and accountants. Plus of course restrictions on what charities can do. For example, I know the disabled car example, they make loads of grants to disabled people from the profits. But the thing is, selling a car for the best price, and then giving a grant to keep someone trapped in the system, looks good. Just selling the car cheap looks like an abuse :-(

It happens SOOO often :-(

Cheers,
Wol

GFP flags and the end of __GFP_ATOMIC

Posted Mar 2, 2023 11:46 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

I think much of what you describe does not relate to some vague, unenforceable duty to maximise shareholder value, but simply is down to a requirement that assets be handled in a responsible way in the interests of the corporation - and not be corrupted by employees' interests.

GFP flags and the end of __GFP_ATOMIC

Posted Mar 2, 2023 14:19 UTC (Thu) by Wol (subscriber, #4433) [Link]

I would agree. The problem is that - especially but not only in the case of charities - "acting in a responsible manner" is *actively*harmful* to the interests of the people it is supposed to be helping.

All the disabled people harmed in my Motability example - including us to the extent we now won't touch the scheme with a barge pole - a scheme that is there explicitly to help us.

The village hall that was sold off and the money spent on facilities in the town ten miles away that "villagers can still make use of it in the town" except there is no viable transport except private car - and the main users of the hall are elderly who don't drive ... (that was my mother's village hall).

That's why the US military buy 50cent hammers for $10 - so they can prove they're not wasting money ...

The AIM is laudable, the end result is execrable.

Cheers,
Wol

GFP flags and the end of __GFP_ATOMIC

Posted Mar 2, 2023 15:01 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 responses)

> Some corporations are protected by their Articles of Association, but even then ...

Interesting. Here if you want to create a new legal personality (i.e. a limited liability company) you need to have Articles of Association. And a standard part of them, usually one of the first articles, is "the purpose of the business". Maximising profit is not usually listed there. An organisation I do some things for actually lists "to help the local community because more self-supporting in energy needs". Maximising profit is not a goal.

But then I look at the A of A of Shell and that part is missing completely.

In the end, shareholders make the final decision (if you have any), and from experience if you have pension funds as shareholders, they are far more interested in a consistent dividend than maximising profits. They'd prefer you having a constant return for the next 30 years than trying to maximise growth and going bust in 5.

The example you give for charities is sad. It seems crazy there's a legal obligation to work that way.

GFP flags and the end of __GFP_ATOMIC

Posted Mar 2, 2023 16:52 UTC (Thu) by Wol (subscriber, #4433) [Link]

> In the end, shareholders make the final decision (if you have any), and from experience if you have pension funds as shareholders, they are far more interested in a consistent dividend than maximising profits. They'd prefer you having a constant return for the next 30 years than trying to maximise growth and going bust in 5.

In the past, that used to be true here. Then the Vulture Capitalists descended. Pension funds are subject to the same short-term pressures as everybody else, forced to make crazy decisions that actively harm savers, and the entire country suffers :-(

Rule 1 of successful saving - choose a staid, reliable provider and just forget about it. Market pressures - "manage your pension! Make sure you're getting the best return! The more we can bamboozle you into paying excessive management fees the better we look to out stakeholders!" (And in the meantime we can raid charge sky high transaction fees and strip the pension cupboard bare.)

Pension savers are actively encouraged to "manage your pension". Excessively managed pensions demonstrably produce poor returns. And yet nobody in authority notices anything wrong, they're too busy encouraging the bandwagon.

All heavily driven by the collapse in "final salary" pensions and the growth of "money purchase".

Cheers,
Wol

GFP flags and the end of __GFP_ATOMIC

Posted Mar 8, 2023 20:08 UTC (Wed) by immibis (subscriber, #105511) [Link] (1 responses)

not exactly the same, but in a similar vein that may be relevant: https://neritam.wordpress.com/2023/02/12/calling-a-fascis...

GFP flags and the end of __GFP_ATOMIC

Posted Mar 8, 2023 20:16 UTC (Wed) by corbet (editor, #1) [Link]

...and you're replying to a month-old comment ... on an article about low-level memory-allocation flags ... I don't really think this subthread needs to go any further.