We are a young startup building modern software for European defence. Looking for generalists, especially with experience in: Web backend (FastAPI, Python), Audio processing (including Voice To Text models), Frontend (modern JS frameworks)
> The use of trampolines requires an executable stack, which is a security risk. To avoid this problem, GCC also supports another strategy: using descriptors for nested functions. Under this model, taking the address of a nested function results in a pointer to a non-executable function descriptor object. Initializing the static chain from the descriptor is handled at indirect call sites.
So, if I understand it right, instead trampoline on executable stack, the pointer to function and data is pushed into the "descriptor", and then there is an indirect call to this. I guess better than exec stack, but still...
They only need trampolines when they access their local environment and you take their address. Without optimization a trampoline was generated whenever an address was taken, but I recently changed this in the development version of GCC to only do this when needed, so hopefully in the next released version you will not get a trampoline for many more cases. Here, there is no address being taken anyway, so you do not get a trampoline.
(and I hope we get a solution without trampolines for the remaining cases as well)
I always assumed that when one warp waits for results from a long latency instruction, another warp, potentially from another block can be scheduled in.
I guess this post assumes the need to use all the gpu resources from within a single block.
> I always assumed that when one warp waits for results from a long latency instruction, another warp, potentially from another block can be scheduled in.
Yes, that is correct. However, most MMA-style kernels that utilize the Tensor Core usually need enough resources per block that only 1 block fits on each SM.
When I was playing with arduino geiger counter, apart from of course breaking the tube, I struggled with counting the results.
On one hand it's trivial - counts (ticks) per second. However, this (of course!) can be very spiky. I ended up using pretty simple EWMA to smooth the results for user interaction. Anything really works, short decay is fine.
Then the really fun bit, was trying it with more serious radiation source, and guess what.... interrupt per tick, is... really bad! I was easily able to overwhelm the arduino, too many interrupts. Fun project to understand interrupt masking.
From a quick skim through the text, it seems to define what an immobiliser is, how it should work, and how it can be advertised on a car.
I don't see anything in there about them being mandatory across the EU. I know some member states passed laws mandating them before that document was published. Perhaps I got the wrong document.
Also take a look at 74/61/EEC. Some form of “immobilizer” has been required in Europe since 1998, and between actual ECE/UN directives and insurance partnerships, the standard increases every few years.
Let me share a personal story. Back in 2014 when I was working at Cloudflare on DDoS mitigation I collaborated a lot with a collage - James (Jog). I asked him loads of questions, from "how to login to a server", via "what is anycast" to "tell me how you mitigated this one, give me precise instructions you've run".
I quickly realised that these conversations had value outside the two of us - pretty much everyone else onboarded had similar questions. Some subjects were about pure onboarding friction, some were about workflows most folks didn't know existed, some were about theoretical concepts.
So I moved the questions to a public (within company) channel, and called it "Marek's Bitching" - because this is what it was. Pretty much me complaining and moaning and asking annoying questions. I invited more London folks (Zygis), and before I knew half of the company joined it.
It had tremendous value. It captured all the things that didn't have real place in the other places in the company, from technical novelties, through discussions that were escaping structure - we suspected intel firmware bugs, but that was outside of any specific team at the time.
Then the channel was renamed to something more palatable - "Marek's technical corner" and it had a clear place in the technical company culture for more than a decade.
So yes, it's important to have a place to ramble, and it's important to have "your own channel" where folks have less friction and stigma to ask stupid questions and complain. Personal channels might be overkill, but a per-team or per-location "rambling/bitching" channel is a good idea.
> I collaborated a lot with a collage - James (Jog). I asked him loads of questions, from "how to login to a server", via "what is anycast" to "tell me how you mitigated this one, give me precise instructions you've run".
Hi, that's me! There were definitely a lot of fun conversations.
I liked that a culture of internal blogs became a thing too. It was good to see people brain dumping their experiments and findings. I think people learnt a lot from following all the internal blogs.
Always funny to see these sort of missed connections on HN.
> internal blogs
In my personal experience the problem is the total lack of writing culture at non-premiere companies.
Put differently: unless you’re working on a great team at a great organization roughly 90% of people cannot be expected to write/read well as a component of technical collaboration. Any thoughts on that? I may just be too cynical
From my personal experience, internal Wikis are 90+% written by about 5% of the workforce. The vast majority of internal Wiki users are "read-only". That is fine. Really: Read that twice. It is OK that the vast majority of docs are written by the few who are highly motivated to do it. When I write for an internal Wiki, I am trying to reduce the number of future questions that people will ask me. If they do come with a question, my first answer is always: Did you search our Wiki? It only takes once or twice for them to change.
I'm not sure it's really cynical at all, in my experience, even with a LOT of wiki documentation, it is almost always severely out of date and many people don't know what is where... after a while, there's new, new, new versions of docs because people didn't want to refactor existing docs someone else created. And, in the end, almost nobody reads it and just ask other, more senior people within the team/org.
This is, of course, without explicit management directives to update documentation as a task/chore. Much like in many (most?) orgs, churning through technical debt is rarely a priority.
That said, no place is perfect and it takes only a handful of people to improve a culture, but without at least management support and/or fostering such a culture, it doesn't tend to happen.
But the non-premiere companies also do not hire the talent that is capable of doing this (and that might be fine, they might not really need that specific talent).
I've many friends that worked most of their carreers in small to medium companies where this wasn't a thing and stuff mostly worked. We can't expect to replicate the high end tech experience everywhere, I doubt it is a good investment of resources.
Reading comprehension is declining. Emphasis on individual "impact" and deadline pressure, common at both premiere companies and "non-premiere" companies mindlessly copying the former, both consume time that could have been spent thinking, writing, and engaging with optional things others wrote. People who avoid documents because they might get outdated create systems with no documentation at all. And now, LLMs promise a world where documents don't need to exist a priori -- a model will look at your code and generate a plausible description of possible intent and system architecture on demand, if someone implausibly happens to ask for documentation. If nobody happens to ask, that's even more time saved - a win-win!
Leadership can either support or inhibit the culture of writing and reading. However, modern managers are not immune from the rising pressure. Their response is to shift from thinking and deliberate information processing to rapid-fire pattern matching. Some of them don't see documents as "real output" to begin with, and operate solely in meetings without any written record or documentation whatsoever. Of coures their staff will pick up on the pattern. I have a vivid memory of engaging with a full team working on a substantial project in the absence of their senior leader, getting the tactical picture and then asking the team about the project's goal. You could have heard a pin drop. None of the people working on the project could speak about anything but their immediate assigned tasks.
Internal blog is another thing, but indeed related to chat. Once we figured some techical thing out, I often put it under "personal blog" on wiki under something like ~marek/date-slug. (I'm actually quite upset about jira removing slug from the url and replacing it with random number, this makes url completion much worse. I often titled the wikis funny/witty to make it easier to remember and find)
These were usually quite short notes. Like I did this and that. Or here are instructions I've run. Pretty much a "lab notebook".
Again, this was often useful to people. Folks new what I was working on at that time. Over time more people adapted this style of public note taking (within company), but I have the impression I was more consistent than others.
I did it for many reasons. I genuinely forget things. It was always nice to see comments (like James complaining that I shouldn't do `dpkg -i x.deb`, and instead finally install the package repo in apt-sources!). So again - searchability (a form of documentation), reach (getting feedback), and work log (for planning).
The format was also nice - short, without specific audience in mind. Zero drama, zero effort. Plentiful and low quality. Because it was "blog" and not "pages", this meant it was obvious when the note was written and nobody expected old blogs to be up to date. The lower the friction in note taking - the better.
Finally, I was working with an SRE team, which was tightly knit and communicated very often over daily checkins (which I wasn't invited to) and other informal channels. And I worked from home a bit. This meant I had to find an asynchronous way to communicate with the team. My personal blogs worked nicely. I highly recommend this style to anyone working remotely.
Although I must admit the personal "lab notebook" wiki thing is not scaleable. It's impossible to "follow" more than a handful of people.
I kept statistics. It's fairly obvious when I was most productive. Here it is, my internal blogs on the wiki per quarter:
I understand the point you were making, but from a manager’s perspective this format is something we’ve tried to avoid. Having a place to have people ask questions is great and encouraged, but doing anything that starts gravitating the knowledge toward a person instead of a topic creates problems for discoverability, searchability, and risks creating the impression (for new employees) that certain specific people are at the center of projects they just happen to know a lot about.
So while the Q&A format is good to have available, I’d discourage creating separate channels around a person. I would encourage everyone to just go to the appropriate topic channel and discuss it there.
I do the same thing when someone starts asking specific technical questions in #random or #general: Redirect to the project specific channel. That’s the place where all of the relevant people will be relevant and watching and it’s the first place they’ll search in the future.
A common mistake that some managers make is pushing the burdens of managing onto those you're managing. Any of us who have been managers can look back and see things that we tried to push down to those we've managed because it made it easier for us while later realizing that wasn't the best solution.
If there's a catch-all channel that employees are using to share knowledge that's not a bug, it's a feature. If, as a manager, you want a more structured means of conveying institutional knowledge generated within such channels then it's on you to put that together. Trying to push that burden down the chain often results in that institutional knowledge being shared verbally or via private emails/DMs in order to avoid the burden of documentation, which is a net negative.
Such information is a force multiplier for teams as well as a great asset for onboarding new hires. Both of those are direct benefits for the manager and the company, so take the advantage of that kind of spontaneous documentation rather than insisting on passing on the cognitive burden.
IMO, the greatest force multiplier in onboarding is automation... How many user interactive steps does a dev need to walk through to get up and running?
I've often gotten this down to a single directory and a primary script you need to run 3-4 times... mostly because of required reboots, such as after WSL setup, also, a few options to set in Docker Desktop. I've done similar with mac/homebrew.
From there, you have docker-compose and shell scripts to run against the projects... these scripts and the compose file(s) are the entry points into a project, actually documenting where things are, and how they connect (to an extent).
Effectively, getting a working solution running sooner than later. This is just my own opinion, but automating a dev environment for onboarding, especially if you're a larger org, is a great tactical decision.
Heavily seconding the “setup script” method for anything that can be scripted in lieu of documentation and handholding. I’ve done this at multiple companies and it proved valuable. Even if it eventually breaks it’s easy to fix, and it’s usually pretty self-documenting, so anyone who’s even a little curious what’s going on, they have access to all the “secrets” of how it’s being done (and can also improve it).
> If, as a manager, you want a more structured means of conveying institutional knowledge generated within such channels then it's on you to put that together
In my case - indeed the name is a historical baggage, I'm not arguing for or against it.
Indeed we had regularly situations that we had to pull in experts from other rooms, to discuss specific topics (like TCP), so we should have forwarded the conversation at the start.
But I don't think this should be categorical. There is value in non-experts responding faster (the channel had good reach) by your non-expert colleagues than waiting longer for the experts on the other continent to wake up.
Maybe there should be an option to... move conversation threads across channels?
I think there is place for both - unstructured conversations, and structured ones. What I don't like about managerial approach, is that many managers want to shape, constrain, control communication. This is not how I work. I value personal connections, I value personal expertise and curiosity. I dislike non-human touch.
"You should ask in the channel XYZ" is a dry and discouraging answer.
"Hey, Mat worked on it a while ago, let's summon him here, but he's in east coast so he's not at work yet, give him 2h" is a way better one.
I know that concentrating knowledge / ownership at a person is not always good, but perhaps a better way to manage this is to... hire someone else who is competent or make other people more vocal.
And yes, I don't like managers trying to shape communication patterns.
OTOH I hugely appreciate my manager who makes a conscious effort to direct people to ask questions in public channels and not just ping “hey” in my DMs all day. And it saves them time too, because my response is going to be “you should ask in channel xyz”. (And yes, in that public channel I am likely to be the one who answers it, but not always, and it’s now visible for other people who also need to know - the exact problem you were so proud of solving!)
The best Slack culture I ever saw also had a strict “No DMs” policy. All discussions had to take place in public or semi-public channels. DMs were reserved for “hey you’re missing standup” or similarly trivial stuff.
> I know that concentrating knowledge / ownership at a person is not always good, but perhaps a better way to manage this is to... hire someone else who is competent or make other people more vocal.
> And yes, I don't like managers trying to shape communication patterns.
I'm a manager who shaped communication patterns (e.g. default conversations to a public channel) because we're solving different problems. By moving conversations to a public channel away from an individual, we're improving redundancy and reducing single points of failure. Our primary responsibility, which understandably garners discontent, is to prioritize the system over the needs of individuals, within reason.
There are many issues resulting from defaulting conversations in private channels or DMs that you've probably seen first-hand.
A slightly different viewpoint is that sharing in public or larger private channels allows for knowledge sharing and collaboration. Sometimes the key person is wrong because they aren't the only one working on something. I know that ego might get in people's way sometimes but other people in the team and in the organization also have valid perspectives. As a manager, its important to try and get to a best solution and that means collaboration, not a specific person's approach all the time.
The redundancy also helps the key person be able to disconnect when on vacation. If you are the sole knowledge base for some critical part of the company, might as well drag the work laptop with you every where you go.
I like this post. It has the right balance between uncomfortable reality and some humour!
All middle managers (in my experience) talk a big game about reducing/preventing key person dependencies, but on 100% of my teams, there were always multiple key person dependencies. The real issue: If you are not the key person for anything, you are the easiest to layoff (fire).
That's the remote equivalent of banning informal conversations in the hall and saying "save it for the daily team meeting".
It feels good as a manager to formalize things, but the best collaboration and ideas happen organically at less formal times and places - and those times are worth at least as much, if not more to the company than anything formal.
You might as well say "no thinking about work in the shower."
Ouch, my wife has encountered almost exactly that in a recent brush with a biotech company that seems to have been infected by FAANG expats. She was advised that any kind of sidebar conversation is a faux pas.
I struggled to guess at the real motive. Is it some project manager's blatant control freakery? An org-level, cynical management attempt to commoditize their knowledge workers? Or some kind of emergent failure where culture morphs through openness -> radical transparency -> enforced conformism a la 1984?
This is the difference between a good idea and the implementation.
People just act differently in "official" topic channels.
It's like when you buy that super secure door lock and the lowest bid handyman bends it while installing because it's such a pain to align correctly and now it's just as vulnerable as any other lock.
yep, also doscoverability is not an issue with Slack. You can find most things with a search, people typically don't go scrolling through a channel to find something.
Slack's search is … okay … but there are any number of times when I have issues finding a thread I was looking at prior.
For all the AI hype that is the current time, search still can't a.) rank the alert bot that is just spamming the alerts channel as "not relevant" when "sorting by relevance" or b.) … find the thread when I use a synonym of an exact word in the thread.
Or the other day I was struggling to find an external channel. I figured it should be easy. But again, I chose a synonym of the name, so miss there, but I though still — by management edict, all of our external channels start with #external-, I'll just pull up all external channels and linear search by eyeball … but management had named this one #ext-…
> search still can't a.) rank the alert bot that is just spamming the alerts channel as "not relevant"
I find "Exclude automations" toggle to be good enough. But we might have very different workspaces, as I usually don't see the point of "sorting by relevance" at all: for my purposes, relevance is almost always better approximated by date than whatever Slack's ML team comes up with.
Yes - not only is Slack search underpowered, but also records management folks are likely to configure pruning of Slack content older than a couple years or so. This is IME less likely to be a problem with wiki pages.
This is why so few people have loyalty to a job. Managements role appears to be simply killing all individuality and fun in the workplace.
"First Warning, this is an unauthorized topic in an incorrect location. You are permitted to discuss this topic but only in the predesignated area."
"Did you complete your TPS reports this morning?"
"Yeah... I'm going to need you to come in on Saturday. We have a go live in 3 weeks for our mini waterfall agile release and you currently have 2 bug tickets assigned."
This murders the last spark of connectivity for remote workers who are already left out of the daily in person banter and bonding that in office work provides.
Comments like these really make me appreciate that we are simply numbers in a spreadsheet and no longer real people to companies and leadership.
Oof. From a manager’s perspective why don’t you focus on getting this information being in place for your team so that they are productive? You could feed that content into a platform the is searchable, categorized and part of onboarding. Utilize utilities that will automate collecting information, rather than discouraging learning.
Focus on eliminating tribal knowledge, implementing a learning culture.
I get the need to call a peg a peg, but it's also good to allow a little fun as well or you end up with these dementors sucking the life out of a company.
For a slack group, I think it's relatively harmless if the focus is around casual shoot the shit convos.
FWIW it's not something I asked anyone to do. The practice started organically and continues to exist because everyone created their own channel and kept going with it.
One thing I suggested was that they should be muted by default so that they aren't a distraction and don't set the expectation that they should be read.
I thought it would be interesting to write about because it was an emergent practice that seems to be sticky and useful within our team.
As a CEO 'manager' myself, I try to let people just be. Getting too granular about person vs. topic and redirecting people to the right room sucks the fun out of everything. Let people mess up and post in the wrong place, who cares?
OP's post was about a great experience 'tremendous value' they had and now you're pooping on it with 'manager' opinions. Read what you wrote from the employee perspective, you're sounding like the self-appointed fun police.
If people have found an effective way to communicate information, leave them the hell alone. I have too often seen people like Auronis decide to come in and manage something to be proper, and then destroy the communication.
The appropriate thing to do is to find a way to augment, without interfering, the channel to shore up any weaknesses.
Formal channels are often too formal - people don't want to look dumb, or get chastised for asking something incorrectly. Formal channels are intimidating, not welcoming.
The point is knowledge sharing, not "appropriate" knowledge sharing.
I love how the OP was like, "hey, we created this informal channel and communicated valuable info to the whole company", and then Auronis is like, "yeah, don't do that!"
We have an organic channel like this that's just called "Study Hall". People constantly ask technical questions and they know it's a judgement free zone. Probably one of the most productive chat channels in our org.
that's the thing that's so inorganic about this whole thing : it's not a judgement free zone, it's a zone that tricks people into presuming that.
If some underling somewhere says something that exposes their ignorance or naivety to either a policy problem or a technical problem you'd better realize that it's going to trigger a 'review mechanism' somewhere down the road within the organization; to think otherwise would be pure fantasy.
Similarly : if you go drinking with the boss, you do still have to remember that the drunk puking slob who you're carrying to their hotel room is going to wake up and be your boss tomorrow.
very few humans actually disconnect this stuff from their internalized judgements of people.
> that's the thing that's so inorganic about this whole thing : it's not a judgement free zone, it's a zone that tricks people into presuming that.
I am surprised that I had to scroll this far to find this observation. If I see a person's posts in multiple channels, I don't switch ON and OFF my mental image of them based on channel like a SQL where clause where channel <> personal. Based on the same premise, the person posting also probably knows this fact and isn't going to be totally free and relaxed asking whatever comes to their mind due to fear of judgement - the same eyeballs are going to be looking at the posts, irrespective of the type of channel.
As someone posted elsewhere, it is all going to be cultural and if that is right, it pretty much doesn't matter how you structure channels.
Yeah, maybe I’m small-minded, but if someone I’m not familiar with, say a new hire asks a question way beneath their presumed experience level I’m absolutely gonna judge, judgement free be damned; and if they’re my report I’m gonna question the hiring (in my mind). There’s no shortage of imposters in the industry, most of them who’re capable of landing jobs above them are probably also smart enough to scoff at pure fantasy like “judgement free zone”.
Having spent a long time in tech and worked with a lot of people I've realised there are two sorts of people who are "imposters". There are those who have BS'd their way up and are in a role where they're out of their depth, and there are those who were lucky to have landed a role that's a bit beyond them (often because they have deep experience elsewhere.)
The first type don't ask questions. They know they're imposters and don't want to be called out.
The second type do ask questions. They also know they're imposters but they're trying to learn so they're not.
Judge people on their actions else you'll only spot the second group, and often with a bit of support those ones can go on to do great things, especially if they're experienced at one thing but they're not learning a new thing. When they get enough knowledge to connect the two things they can be absolutely brilliant.
There's no such thing as a judgment free zone when humans are involved :-)
I tell new hires that they shouldn't be scared of asking questions, and that if they're not asking questions they're probably not pushing themselves enough. But also caution to make sure that they check available resources first, and then ask the right audience.
I'm a tech lead and I also tried to encourage the judgement free zone on the devs channel. I do this by intentionally asking question that I should know the answer to but don't as I just never got around to figuring it out as I have 16k other things to worry about. So rather than spend 2 hours chasing something down, I just ask. I know that this is a question a lot of juniors can answer. I avoid people thinking I am dumb by also taking time to answer the more technical questions and posting architecture and optimizations on the same channel.
This strikes me as a somewhat unfair characterization of many of these communities. In my experience, a much more common issue is that the people who do have answers end up ignoring the group and it becomes pointless. It rarely becomes a source of career hindrance or long-lasting judgement, it just ends up being useless because there's not a lot of incentive for the expert side of the equation.
People who are likely to judge people for dumb questions are rarely involved in those groups in the first place, for exactly all the obvious reasons.
The more realistic outcome isn’t that your boss ends up a drunk puking slob (and for what it’s worth most of these groups don’t include leadership anyway, so not sure why anyone's boss would be involved) but that an intern floats a terrible idea ("I'm thinking of taking these 10 shots of 151"), nobody responds, they take silence as approval, and they end up causing a mess and then being judged for the mess they caused.
A quick gut check from them with a healthy group might get a few eye rolls and a "here's why that's a bad idea", but not any lasting judgement unless they completely ignored the advice.
The only case I can think of where that might happen is if they already did something which has policy or legal implications ("hey i accidentally dumped the whole user base including PII to my phone"), in which case - good? There should be a review mechanism, including consequences if they ignored a bunch of roadblocks.
> It rarely becomes a source of career hindrance or long-lasting judgement, it just ends up being useless because there's not a lot of incentive for the expert side of the equation.
Yeah, the incentive structure for something like this is totally misaligned for this to work effectively in many cases outside of a very small, tight-knit team. (In which case... why the formality in the first place?)
For the "juniors": Why waste time digging through documentation, searching, or thinking--I can just post and get an answer with less effort.
For the "seniors": I'm already busy. Why waste time answering these same questions over and over when there's no personal benefit to doing so?
Sure, there are some juniors that will try and use it as a last resort and some seniors that will try their best to be helpful because they're just helpful people... but I usually see the juniors drowned out by those described above and the experts turn into those described above.
I think we _could_ come up with something that better aligned incentives though. Spitballing--
Juniors can ask a question. Once a senior answers, the junior then takes responsibility for making sure that question doesn't need to be answered there again--improving the documentation based on that answer. Whether that's creating new documentation, adding links or improving keywords to help with search, etc. That change then gets posted for a quick edit/approval by the senior mainly to ensure accuracy.
Now we're looking at something more like:
For the "juniors": If I ask a question, I will get an answer but it will create additional work on my end. If I ask something already answered in the documentation that I could have easily found, I basically have to publicly out myself as not having looked when I can't propose an improvement to the documentation. And that, fairly, is going to involve some judgement.
For the "seniors": Once I answer a question, someone is going to take responsibility for getting this from my head into documentation so I never need to answer this again.
This has an added benefit of shifting some of the documentation time off of the higher paid, generally more productive employees onto the lower paid, less productive employees and requiring them to build out some understanding in order to put it into words. It may also help produce some better documentation because stuff that a senior writes is more often going to assume knowledge that stuff a junior writing may think to explain because _they_ didn't know it. It also means that searching in the Slack/other channel, any question you find should end up with a link to the documentation where it's been answered which should help you discover more adjacent documentation all of which should be the most up-to-date and canonical answer we have.
I’m on board with the overall point, though I’d actually flip the logic in this section:
> Once a senior answers, the junior then takes responsibility for making sure that question doesn't need to be answered there again.
That might make sense for simple questions. But for anything more complex, especially when the issue stems from something you have control over, having senior folks take ownership might make more sense. If they can tie the fix to visible impact, there’s a strong incentive for them to actually solve the root problem. Otherwise, there’s always the risk that experienced team members simply ignore the question 100% of the time (which also solves the problem of "i've already answered this question").
One way seniors might approach these types of groups is by treating them as a source of ideas. Repeated questions like “how do I use X?” might indicate that X needs a redesign or better onboarding. An experienced corporate climber could treat those questions as justification for "X 2.0 which is way easier to onboard to" and get backing to work on it.
Anyone who’s spent time at a large tech company has likely seen this dynamic play out, because it’s a common pathway to promotion. Definitely taken to problematic extremes, no doubt, but a slightly-healthier version of that playbook still beats the alternative of relying on the arcane knowledge of a select few as gatekeepers of information.
As a senior judgement is a real problem as others have suggested. I suspect its a reason why AI is popular. I can ask those dumb questions I should know without embarrassing myself by asking someone, or even worse put it in writing with my name on it.
Memory page size should be transparent for tagged pointers (any pointers, really), I don't see how they can be affected. You have an object at address 0xAB0BA, does the size of underlying page matter?
It can be an issue of behavior; for example, Redis recommended disabling transparent huge page support in Linux because of (among other things?) copy-on-write memory page behaviors, and still does if you're going to persist data to disk.
1. You have a redis instance with e.g. 1GB of mapped memory in one 1GB huge page
2. Redis forks a copy of itself when it tries to persist data to disk so it can avoid having to lock the entire dataset for writes
3. The new Redis process does anything to modify any of the data anywhere in that 1GB
4. The OS has to now allocate a new 1GB page and copy the entire data set over
5. Oops, we're under memory pressure! Better page out 1GB of data to the paging file, or flush 1GB of data from the filesystem cache, so that I can allocate this 1GB page for the next 200ms.
You could imagine how memory allocators that try to be intelligent about what they're allocating and how much in order to optimize performance might care; when a custom allocator is trying to allocate many small pages and keep them in a pool so it can re-use them without having to request new pages from the OS, getting 100x 2M pages instead of 100x 4k pages is a colossal waste of memory and (potentially) performance.
It's not necessarily that the allocators will break or behave in weird, incorrect ways (they may) but often that the allocators will say "I can't work under these conditions!" (or will work but sub-optimally).
This just provides yet another example of why tagged pointers are a terrible idea and shouldn't be used. Someday, more of the address space will get used and your software will break.
I'm not following. I thought the whole issue is that users _do not_ want to use microsoft account locally and that microsoft fights that.
reply